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PRE 


ABOUT THIS HANDBOOK 


The DOI Handbook is the main source of information about the DOI System’. It describes 
the DOI System at business and technical levels and assists the community in understanding 
the system and Registration Agencies (RA) in providing services based on the system. 


Other information resources, such as factsheets and FAQs are available on the web site and 
are cited from this handbook where relevant. 


AUDIENCE 


This handbook is directed at anyone who is involved in services provided through the DOI 
System, or who is potentially interested in the DOI System: RAs, application designers and 
developers, RA communities. 


ORGANIZATION 
This handbook contains the following material: 


e Chapter 1: DOI System Overview This chapter introduces the DOI System's history, 
purpose, basic principles, benefits and applications. 


e Chapter 2: DOI System Governance and Participation This chapter describes the role 
and functions of the DOI Foundation and of Registration Agencies within the DOI System. 
It also summarizes the policies governing the DOI System and explains the policy formu- 
lation process. 


e Chapter 3: DOI Namespace This chapter defines the syntax for a DOI name. It also ex- 
plains the DOI name assignment principles and how other identifier schemes can be inte- 
grated into the DOI system. 


e Chapter 4: DOI Metadata This chapter explains the basis for one of the main technical 


components of the DOI System, the DOI data model, and its ability to ensure interopera- 
bility of DOI name metadata assigned through metadata schemes. 


1 DOI https:/ /doi.org/10.1000/182 identifies the latest current version of the handbook 


DOI Handbook 


Chapter 5: DOI Identifier / Resolution Services This chapter describes the identifier / 
resolution services included in the DOI System package. 

Chapter 6: DOI Applications This chapter discusses some of the ways in which resolu- 
tion can be harnessed to provide applications with the ability to resolve a DOI name to 
the most appropriate content chosen from multiple DOI resolution options. These options 
can include pop-up menus offering manual selection, and consistent automated selection 
through content negotiation and Linked Data. 

Chapter 7: Designing and Developing a DOI Application This chapter assists business 
analysts and developers in designing and developing applications based on the DOI Sys- 
tem. 

Chapter 8: Defining RA and Registrant Policies This chapter assists the Registration 
Agencies or registrants in defining their own policies. 

Chapter 9: Operating and Maintaining the RA Services This chapter assists the Regis- 
tration Agency's service operations team in performing service operation tasks. 
Appendix 

Glossary 


Index 


STANDARD DOCUMENTS 


The main standard documents related to the DOI are: 


ISO 26324:2022 "Information and documentation — Digital object identifier system" 


"Digital Object Identifier Resolution Protocol (DO-IRP) Specification" version 3.0 June 
2022. 
https:/ /www.dona.net/sites/default/files/2022-06/DO-IRPV3.0--2022-06-30.pdf 


Notice: The DOI Foundation welcomes the publication of the Digital Object Identifier 
Resolution Protocol (DO-IRP). This specification is made available by DONA, a Swiss 
Foundation set up to govern the Handle System® (as used by the DOI infrastructure) and 
promote associated specifications. The Handle System was previously specified only in 
"informative" documents and the publication of proven, normative documents that re- 
move features that were never implemented will increase the robustness and reliability of 
the DOI infrastructure. This infrastructure is used over 12 billion times a year to resolve 
over 300 million DOI names across the different sectors that rely on it. Most users access 
the DOI infrastructure through the resilient network of web proxies at https:/ /doi.org 
and never encounter the Handle System directly, but this publication will ensure that the 
DOI System remains world-class into the future. 
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1.1 HISTORY AND PURPOSE OF THE DOI SYSTEM 


The DOI® (Digital Object Identifier) System originated in a joint initiative of three trade as- 
sociations in the publishing industry (International Publishers Association; International As- 
sociation of Scientific, Technical and Medical Publishers; Association of American Publish- 
ers). Although originating in text publishing, the DOI System was conceived as a generic 
framework for managing identification of content over digital networks, recognizing the 
trend towards digital convergence and multimedia availability. The system was announced 
at the Frankfurt Book Fair 1997. In the same year, the DOI Foundation was created to de- 
velop and manage the DOI System. 


From its inception the DOI Foundation worked with the Corporation for National Research 


Initiatives (CNRI?) as a technical partner, using the Handle System®? developed by CNRI as 
the digital network component of the DOI System. CNRI remains a technical partner of the 
DOI Foundation as the DOI technical support service provider. 


From 1998 the Foundation worked closely with the INDECS project (1998-2000) and a 
number of subsequent and continuing initiatives building on this. The INDECS framework‘ 


underpins the DOI data model. 


The DOI System provides a technical and social infrastructure on which organizations can 
build applications to provide services to users or communities of users. For example, the 
DOI System is used in internal processes in multiple industries, for publishing and reporting 
across corporate and national boundaries, and in the field of semantic web applications. 
Because of the widespread implementation of the DOI System, the DOI Foundation was in- 
vited to propose it as an ISO standard. ISO 26324 was published in 2012 and updated in 
2022. The ISO standard specifies the syntax and operation of the DOI while leaving imple- 
mentation issues to the Foundation, which acts as registration authority for the standard. 
Note that the DOI Syntax was originally a National Information Standards Organization 


(US) standard, ANSI/NISO Z39.84-2010, first published in 2000 and withdrawn in 2017. 


1.2 BASIC PRINCIPLE: INTEGRATION OF IDENTIFIER RESOLU- 
TION AND SEMANTICS 


The DOI System provides: 


e an identification system of entities based on the Handle System, a globally distributed 
system for resolving identifiers 
Any entity (digital, physical, or abstract) can be identified by a global unique and per- 
sistent identifier called a DOI name. The DOI name can be resolved to a resource, such 


2 https:/ /www.cnri.reston.va.us/ 
3 https:/ / www.dona.net/handle-system 
4https://www.doi.org/the-identifier/resources/factsheets/the-indecs-framework 
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as a web or internet resource, metadata describing the entity, a landing page with ac- 
cess to further resources, etc. 

For example, a DOI name representing an article resolves to the web address of the 
HTML file version of the article. 


e a metadata model based on the INDECS interoperable metadata framework 
Metadata must be assigned to each DOI name to describe the entity represented by the 
DOI name. Metadata interoperability is ensured through basic principles outlined by the 
DOI Foundation. 
Metadata is used to provide services to the users: it can be displayed to users to enrich 
an information resource; it can be used by users to search for a DOI name; etc. 


The figure below illustrates the basic principle of the DOI System. 


Represents 
Interoperable Unique and 
metadata model Melad d apia paara 
based on the — pone ged based on 
INDECS framework “the TE System 
Resolves to 


May b t 
Adds values Ee jed description of 


Figure 1 Basic principle: integration of identifier resolution and semantics 


1.3 IDENTIFIER / RESOLUTION SYSTEM WITH THE HANDLE 
SYSTEM 


For its resolution services, the DOI System is an implementation of the Handle System’, a 
general-purpose distributed information system designed to provide an efficient, extensible, 


and secured global name service for use on networks such as the Internet. 


1.3.1 DOI NAME: UNIQUE AND PERSISTENT IDENTIFIER 

A DOI name is a global unique identifier of an entity (called the referent). The referent can 
be any digital, physical or abstract entity, and it can be defined on any granularity level of 
an entity depending on the requirements of the Registration Agency (RA); and a DOI name 


5 https:// www.dona.net/handle-system 
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may identify a specific edition of a novel, a novel chapter, a small piece of musical record- 
ing, etc. Referents can be intellectual property where examples would include inventions, 
literary and artistic works, ideas, symbols, names, images, designs, etc. 


A DOI name can be resolved, through a Handle System service, to a set of elements, called 
the DOI record, as illustrated below. The DOI record usually contains a web address (or 
URL for Unified Resource Locator) representing an instance of the referent, and may contain 
services such as email, and one or more items of data about the referent (metadata). 


DOI record 


Referent g 


Figure 2 DOI name concept 


The figure below shows an example where the referent is the specific edition of a novel. A 
referent could also be a chapter of the novel, etc. 


6 = 


Novel 


doi 0002 


Figure 3 DOI record example 


The DOI name is persistent over time. Its persistence is provided by the independence of the 
identifier name from the element values, in particular from the entity localization or owner- 
ship. These elements can change over time: through the DOI name resolution, users will al- 

ways get the up-to-date element values (This requires that the DOI record data be regularly 
maintained. ). 


NOTE Each element of the DOI record is assigned an explicit type (for example, "URL" (web ad- 
dress) or "email"). Predefined types exist in the Handle System and new types can be added by 
RAs, making the DOI resolution system extremely flexible and responsive to new requirements. 


1.3.2 DOI NAME SYNTAX 


The DOI syntax follows the Handle System's rules and is as follows: 
<prefix>/<suffix> 


where: 


e prefix: refers to the DOI namespace (a namespace is allocated to a given service pro- 
vider) 
The prefix can contain only numeric values and the "." character which is used to delimit 
a hierarchical level in the namespace allocation: a one-delimiter prefix (for example, 
"10.1000") derives from a zero-delimiter prefix ("10"). 
In the Handle System, the prefix 10 is allocated to the DOI Foundation. 


e suffix: is a unique local name in the namespace 
Any Unicode 2.0 character can be used in the suffix (there is no practical limitation on 
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the length of a DOI name). This unique string may be an existing identifier, or any unique 
string chosen by the Registration Agency or the registrant of the DOI name. 


DOI name examples are: 10.1000/xyz-123; 10.1109/5.771073; etc. 
NOTE DOI names may also be expressed as URLs: see 1.5.1. 


For more information about the DOI name syntax, see Chapter 3. 


1.4 STRUCTURED SEMANTICS BASED ON STRICT PRINCIPLES 


The metadata describing an entity is provided by the registrants of the DOI names to the 
Registration Agency (RA) who provides the registration service. The metadata must follow 
strict rules which are guided by a set of principles derived from the INDECS (interoperabil- 
ity of data in e-commerce systems) project. The aim is to achieve metadata interoperability 
and the automated integration of metadata in the DOI System. 


This section introduces the principles and tools of the DOI metadata system. For more infor- 
mation, see Chapter 4. 


1.4.1 PRINCIPLES OF THE INDECS MODEL 


The DOI Foundation is one of the organizations which funded the original INDECS frame- 
work and has continued to develop it further in partnership with an increasing range of or- 
ganizations. Originally, the challenge for the DOI/INDECS project was to create a genre- 
neutral framework among rights-holders for electronic intellectual property rights trading so 
that companies can trade their creations in a coherent single marketplace. 
In the INDECS model, an item of metadata is defined as "a relationship that someone claims 
to exist between two entities". This definition stresses the significance of relationships, which 
lie at the heart of the INDECS work. 
The principles of the INDECS model are: 
e unique identification 
Every entity must be uniquely defined within an identified namespace. 
e functional granularity 
It should be possible to identify an entity whenever it needs to be distinguished. 
e designated authority 
The creator of the metadata must be identified without doubts about its identity. 
e application independence 
The metadata schema should be independent of the technology used. 
e appropriate access 
Everyone must have access to the metadata needed. The consequence of this principle is 
that not all metadata must be accessible to everyone. In certain circumstances, some 
metadata would be inaccessible for certain users. 


For more information, see The INDECS Framework°®. 


Shttps:/ /www.doi.org/factsheets/indecs_factsheet. html 
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1.4.2 STANDARD METADATA DECLARATION 


A standard metadata declaration must be made for every entity identified with a DOI name 
according to the following principles: 


e The declaration must contain a minimum set of mandatory metadata called DOI Kernel. 
This kernel is designed to be as limited in scope as possible, and it is applicable to any 
entity identifiable by the DOI System. 


e Additional metadata can be declared. 
It should be based on an agreed metadata exchange schema if metadata interoperability 
is required with other Registration Agencies (RA). 


e All declared DOI metadata is based on a data dictionary which specifies all data ele- 
ments and allowed values. 


The DOI Kernel as well as the data dictionary are specified through the DOI Kernel 
Schema. This schema is extensible to whatever level of detail and granularity is required, 
and is neutral (it is independent of any business and any implementation technology). It al- 
lows the RAs to use any metadata scheme, yet still ensures semantic equivalence with DOI 
names assigned by others: 


e Terms are added to the DOI Kernel Schema at the request of any RA. 


e The DOI Kernel Schema provides the mappings to support metadata integration and 
transformations required for data exchange between RAs. 

The figure below illustrates the metadata creation flow. The registrant of a referent provides 

the metadata describing the referent. The RA's metadata service creates the corresponding 

metadata declaration(s) according to the metadata schemas and assigns them to the re- 


Is assigned to 


spective DOI name. 
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Kernel 
metadata 
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The registrant of the J 
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Registration Agencies (RA). Data dictiona 
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Figure 4 Metadata declaration 
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For more information, see Chapter 4. 


1.5 BASIC RESOLUTION SERVICES PROVIDED BY THE DOI 
SYSTEM 


The basic resolution function of the DOI System consists in redirecting a user to a web re- 
source on resolution of a DOI name. The end-user can perform this basic resolution request 
from any standard web browser. 


1.5.1 DIRECT REDIRECTION TO A WEB RESOURCE WITH THE DOI 
PROXY 


The most common resolution function of a DOI name returns a single web address (or URL 
for Uniform Resource Locator) to which the user is redirected as illustrated below. This is 
done by using the HTTPS Proxy Server of the DOI System (https:/ /doi.org). With the DOI 
Proxy, users can resolve DOI names from any standard web browser by using the URL syn- 
tax (A proxy server is a web server that understands the Handle System protocol, thereby 
acting as a gateway between the Handle System and HTTPS.). For example, the resolution 
of the DOI name "10.10.123/456" would be done from the address 
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"https: / /doi.org/ 10.123/456". That makes the DOI resolution service extremely easy to 


use. 
A user requests to view a The DOI resolution service 

@ scientific article. This article is © requests the resolution of the DO! 
assigned to this DOI name: name. This DOI record is returned: 


© The DO! resolution service retrieves the 
URL from the DOI record and redirects the 
user to the corresponding web resource: 


= Œ â mdpi.com/1424-8220/18/2/479 2 t å 


32 Apps Reading list 


(mbPr) Q= 


Analysis of Dark Current in BRITE Nanostellite CCD 
Sensors t 


by @ Adam Popowicz © 


Institute of Automatic Control, Silesian University of Technology, Akademicka 16, 44-100 Gliwice, Poland 

T Based on data collected by the BRITE Constellation satellite mission, designed, built, launched, operated and 
supported by the Austrian Research Promotion Agency (FFG), the University of Vienna, the Technical University 
of Graz, the Canadian Space Agency (CSA), the University of Toronto Institute for Aerospace Studies (UTIAS), 
the Foundation for Polish Science & Technology (FNiTP MNiSW), and National Science Centre (NCN) 


doi 0008 


Figure 5 Direct redirection to a web resource 


1.5.2 ADDITIONAL RESOLUTION SERVICES INCLUDED IN THE DOI 
SYSTEM 


The following resolution services are included in the DOI System in addition to the main DOI 
resolution service: 
e shortDOI 
The shortDOI Service creates shortened DOI names, as aliases for existing DOI names, 
which are often very long strings. Applications which resolve DOI names will treat a 
short DOI identically to the original. 
For more information, see 5.5. 
e Which RA? 
This service returns the name of the DOI Registration Agency (RA) responsible for a spe- 
cific DOI name, or group of DOI names. 
For more information, see 5.6. 
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1.6 VALUE-ADDED SERVICES A REGISTRATION AGENCY CAN 
BUILD ON THE DOI SYSTEM 


Registration Agencies can provide various added-value services by using the multiple reso- 
lution request supported by the DOI resolution service. In contrast to the single resolution 
which can only return a single web address (URL) element, the multiple resolution allows 
making use of any useful information in any form returned in the DOI record. While the mul- 
tiple resolution is typically used to acquire mulitple URLs, it is flexible enough to provide in- 
formation for many other applications. 


This section describes some examples of these added-value services. 


1.6.1 MANAGEMENT OF A REFERENT WITH SEVERAL INSTANCES 


In case a referent is linked to several web resources - for example, if an article is available 
in PDF and in HTML versions then two web addresses (URLs) are provided - then a resource 
selection mechanism must be implemented by the Registration Agency (RA). It may be: 


e a manual selection 
When the user requests the referent's DOI name from the RA's application, the applica- 
tion generates a menu of options from which the user performs a manual choice. 


e an automated selection 
The URL to which the user is redirected is automatically selected among a list of provided 
addresses according to predefined rules that may be based on parameters depending on 
the user (for example, the user's geographic location which would be determined 
through their IP address). 
The menu options or the redirection rules are retrieved from the DOI record. In particular, 
redirection rules can be defined through a redirection graph element containing XML code 
which can be interpreted by the DOI resolution service as illustrated below. 


+ D 
A user asks for (2) The DOI resolution 
the resolution of service interprets the XML 
0.3390/s18020479 H code of the redirection 
H graph retrieved from the 
DOI record and returns 


F <condiSon I> FER the resulting URL. 
<URLI >... 
if <condition2> then 


Figure 6 Management of a referent with several instances 


<URL2> etc. 
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1.6.2 DYNAMIC BUILDING OF A WEB PAGE ENRICHED WITH 
METADATA 


On request of a user for a referent, Registration Agencies (RA) can dynamically build a 
web page displaying the metadata assigned to the respective DOI name. The metadata is 
provided by the RA's metadata service responsible for the respective DOI name. The ad- 
dress of this metadata service can be retrieved from the DOI record. 

The figure below illustrates an application where each product of a building structure is 
identified through a DOI name which is printed on the physical product in the form of a QR 
code. When a user scans the QR code, they are redirected to a product landing page 
where they can quickly find all the most up-to-date information on a product. 


< Back to results 
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The QR code contains 
the DOI name 
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Points to Width 49mm 
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Metadata à e nsulfix Track - Half RI3OH. For use with on rafters of minimum depth 130mm where access to 
declarations RA S one sede is restricted. Provides a quick, easy and rel 
. Metadata t tolas the rå ł 
assigned to Service me ) making ! 
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Figure 7 Dynamic building of a web page enriched with metadata 


1.7 BUSINESS AND ORGANIZATIONAL MODEL OF THE DOI 
SYSTEM 


The DOI System is deployed via Registration Agencies (RAs) who are empowered to assign 
DOI names for a community under the governance of the DOI Foundation. 


1.7.1 FEDERATION OF REGISTRATION AGENCIES (RA) 

The DOI System is implemented through a federation of Registration Agencies (RA) who 

provide services to users (registrants): 

e Registration Agencies must comply with the policies and technical standards established 
by the DOI Foundation, but are free to develop their own business model for running 
their businesses. 
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e Users can join a service offered by an RA by registering material with one of them, or 
developing a community to build an RA. 

e Registrants ensure appropriate content management of their own material (maintenance 
of URLs and data), either directly or by contract (for example, with the RA). 


1.7.2 FREE RESOLUTION SERVICE 


The DOI Foundation maintains a DOI Proxy that can resolve all DOI names. Users can be 
any person or machine that wants to resolve a DOI. They do not have to be members of the 
DOI Foundation and may use the DOI Proxy as often as they like. DOls are, and will al- 
ways be, free to resolve. 


1.7.3 GOVERNANCE ROLE OF THE DOI FOUNDATION 
The DOI Foundation is the governance body of the DOI System: 


e It safeguards (owns or licences on behalf of registrants) all intellectual property rights 
relating to the DOI System. 

e It works with RAs and using the underlying technical standards of the DOI System compo- 
nents to ensure that any improvements made to the system (including creation, mainte- 
nance, registration, resolution and policymaking of DOI names) are available to any 
DOI name registrant, and that no third party licenses might reasonably be required to 
practice the DOI name standard. 

e It provides agreed standards of governance, scope, and policy, and also a technical in- 
frastructure (resolution mechanism, proxy servers, mirrors, back-up) and a social infra- 
structure (persistence commitments, fall-back procedures, cost-recovery (on a self-sus- 
taining model), and shared use of the system). 
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1.7.4 DOI NAMESPACE ALLOCATION APPROACH 


The DOI namespace allocation approach is as follows: 


e The DOI Foundation allocates one or several prefixes derived from its top-level prefix 


(10) to an organization that wishes to register DOI names (a Registration Agency (RA)). 


e The RA registers DOI names under their allocated prefix(es). If the RA allocates a sepa- 
rate prefix to each of their customers (registrants) then the combination of a prefix for 
the registrant and suffix provided by the registrant (which is unique within their prefix) 
avoids any necessity for the centralized allocation of DOI names. 


The following figure illustrates the DOI namespace allocation approach. 


ofthe Henle System 


DOI System 
Governance body of the DOI System 
Is allocated the prefix ” 10” through the DONA-MPA 
Hersek etd Administrator) service agreement as 
defined by the DONA Foundation. Can allocate to itself 
or to third parties prefixes derived from its prefix. 


Registration Agencies (RA) 

An RA is allocated one or several prefixes by 
the DOI Foundation through the RA agreement. 
An RA provides registration services for DOI 
names under their allocated prefix(es). The RAs 
decide about the way they allocate their DOI 
namespace but it is recommended to allocate a 
separate prefix to each registrant. 


Registrants (RA Customers) 
A registrant registers DOI names with a 


Registration Agency with which they . 
have an agreed relationship as a Registrant DOI names under Registrant 


customer. If a registrant has multiple DOI names under Prefix 10.11012 DOI names under 
types of content or application Prefix 10.1 1005 Prefix 10.11064 
requirements, they may choose to 

select several RAs. 

1) A workflow for DOI names using prefixes other than 10 has yet to be established. 


Figure 8 DOI namespace allocation approach 


1.8 STANDARDIZATION OF THE DOI SYSTEM 
The DOI System is ISO-standardized. 


1.8.1 ISO 26324 


The DOI System has been standardized through the International Organization for Stand- 
ardization, ISO (within the responsibility of committee ISO TC46/SC9, Identification and 
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documentation) as ISO 26324, Digital Object Identifier System’. This International Stand- 
ard specifies the syntax, description and resolution functional components of the DOI Sys- 
tem, and the general principles for the creation, registration and administration of DOI 
names. 


The DOI Foundation is ISO 26324 Registration Authority: as with other identifier standards, 
the creation of a public standard for the DOI System creates a controlled namespace which 
is populated through the Registration Authority. 

ISO 26324 does not specify specific technologies to implement the DOI System. These are 
selected and implemented by the Registration Authority. 


NOTE Norman Paskin wrote a history/case study of DOI standardization, "The Digital Object 
Identifier: From Ad Hoc to National to International"®. 


1.8.2 CONFORMANCE WITH RELEVANT EXTERNAL STANDARDS 


The DOI System has also been developed to ensure conformance with relevant generic ex- 
ternal formal standards, including URL. 


It implements the Handle System which conforms with the DO-IRP protocol: see Digital Ob- 
ject Identifier Resolution Protocol (DO-IRP) Specification’. 


The DOI Foundation supports the FAIR principles'® which provide guidelines to improve 
Findability, Accessibility, Interoperability and Reuse of digital assets. The FAIR principles 
emphasize machine-actionability (the capacity of computational systems to find, access, in- 
teroperate, and reuse data with none or minimal human intervention) because humans in- 
creasingly rely on computational support to deal with data as a result of the increase in vol- 
ume, complexity, and creation speed of data. Note that FAIR principles may not be relevant 
to some use cases of the DOI System, for example EIDR. 


7 https://www.iso.org/standard/81599.html 

8 https:/ / www.doi.org/resources/DOI_Case_Study_Paskin.pdf 

? https:/ / www.dona.net/sites/default/files/2022-06/DO-IRPV3.0--2022-06-30.pdf 
10 https:/ /www.go-fair.org/fair-principles 
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1.9 PERSISTENCE AS A DESIGN FEATURE OF THE DOI SYSTEM 


Persistence of DOI information is a key aim of the DOI System, and is guaranteed by the 
DOI social infrastructure through policies and agreements, and assisted by technology. 


Table 1 Persistence considerations in the DOI System 


Persistence of the access to 
data in case the referent 
location or ownership 
changes or in case the ref- 
erent is no longer availa- 


ble 


Persistence of the access to 
data in case a Registration 
Agency (RA) is defaulting 


Persistence of the DOI Sys- 
tem in case the DOI Foun- 
dation ceases to exist or 
the current technical imple- 
mentation is unable to sus- 
tain its activities 
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Through the DOI name resolution concept, DOI names resolve to information 
(DOI record) which may change over time (URL, object ownership, etc.) 
while the mapping of the DOI name to the entity persists. It is the responsibil- 
ity of the registrant to maintain the data of the DOI record. 


In case the object identified by a DOI name is no longer available, the DOI 
name registrant can at minimum have the DOI name resolve to a response 
screen indicating that the object is no longer available. 

RA membership imposes certain obligations on an RA to ensure transfer of 
appropriate records and enable continuity of DOI resolution in case the RA is 
defaulting. Membership of the DOI Foundation is predicated on the assump- 
tion that communities wish to work together to ensure long term persistence, 
beyond the interests of their own current applications. Should this assumption 
be false, the DOI agreements provide a fall-back position enabling persis- 
tence of resolution of the assigned DOI names. 


Note: Added-value services available through DOI resolution which are pro- 
vided by a Registration Agency cannot be guaranteed to be maintained by 
the DOI Foundation in the event of the Registration Agency ceasing to exist. 
Such services may require additional material (for example, access to 
metadata look-up or workflow procedures). However, the DOI Foundation 
will make best efforts to transfer such services to another agency, or maintain 
such services itself, or encourage that services are transferred to a third party 
able to provide continuity where required. The aim will be to provide least 
disturbance to the community of users of those DOI records. 

In the event of the DOI Foundation ceasing to exist, agreements are in place 
to transfer the system to other parties. 


The DOI Foundation's agreement with technical support partners allows for 
reversion of all DOI System data, licenses, rights etc. to the DOI Foundation 
in the unlikely event of the current technical implementation closing or being 
unable to sustain its activities. 
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Persistence of the technical | The DOI system uses a globally distributed multiple site network of servers 

infrastructure technology | and service sites overlain on the Handle System, which itself has similar dis- 
tributed sites. These sites are at individual RA member locations, professional 
co-location hosting sites, and virtual (cloud computing) facilities, with re- 
sources to ensure 24x7 cover, mirroring machines to ensure against power 
outages, etc. The DOI Foundation also ensures that the doi.org domain is 
part of the persistent technical infrastructure, including mirroring and load 
balancing to ensure optimal availability for HTTPS requests to the DOI Proxy. 


The Handle System is governed by the DONA Foundation which is committed 
to ensure the system continuity. The Handle System is an open standard, so 


anyone can build/use a Handle service. Both source code and APIs are pub- 
lic. 


1.10 BENEFITS OF THE DOI SYSTEM 


The following paragraphs describe some of the benefits made possible by the DOI System. 


1.10.1 IMPROVED CONTENT MANAGEMENT AND DISCOVERY 


Benefits of implementing the DOI system include facilitating internal content management 
and enabling faster, more scalable product development, by delivering four key ad- 
vantages in making it easier and cheaper to: 


e know what you have 
Users are able to look at catalogues of content available throughout the enterprise. 


e find what you want 
Users are able to search and browse for content to be used or re-purposed. 


e know where it exists 
Users are able to see where the item exists within the organization. 


e be able to get it 
Users and production tools are able to retrieve the content. 


1.10.2 SOLUTION TO THE BROKEN LINK (PERSISTENCE) 


The DOI System provides the means for a solution to the famous web issue of “http 404 not 
found” (broken link). 


The problem is that a URL (Unified Resource Locator) is both an identifier and a locator for 
a resource on the Internet. The specific content of the URL that is its identifier is also the 
string that can be resolved into a location. This has the consequence that when a resource is 
moved from one service to another, from a server to another, or from a company to an- 
other, it will get a new URL that identifies the service, the server or the company that hosts 
it. Its old URL will most likely stop working and any previously made references to that re- 
source using the old URL will no longer work. 
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With the DOI System, the identifier is persistent, whereas the metadata to which it resolves 
can change over time, in particular, the URL can be updated. For more information, see 
Chapter 3. 


1.10.3 IDENTIFIER INTEROPERABILITY THROUGH A POWERFUL 
METADATA MODEL 


Resources of interest in digital networks originate from a wide variety of sources, and may 
carry identifiers from different established public schemes, official standards, de facto 
schemes, or private cataloguing numbering. A key step in facilitating preservation, re-use 
and exchange of information is to enable users to re-use these identifiers (and their associ- 
ated data) across different applications. 


For example, where several Registry Agencies (RA) are issuing DOI names to journal arti- 
cles from different publishers, it is likely that some RAs and publishers will want their DOI 
names to be included in journal-related services supported by other RAs. In a similar way, 
many RAs will want DOI names issued by other RAs to be available for inclusion in services 
they themselves are providing. Such interoperability is one of the principal benefits of the 
DOI System. 


To achieve identifier interoperability in the DOI System, tools and policies are used: see 
1.4. 


1.10.4 COMPATIBILITY WITH OTHER IDENTIFIER SYSTEMS 


The DOI System is not meant to replace existing identifier systems. Instead, it is designed for 
interoperability; that is to use, or work with, existing identifier and metadata schemes. 


The DOI System explicitly recognizes other schemes. The ISO DOI specification (ISO 
26324) sets out the specifications for recognizing existing schemes. At minimum, the DOI 
metadata must record the fact that another registry identifier exists. Additional optional 
steps are possible, including: 


e a consistent way of including the other scheme in the DOI syntax 


e a business relationship to facilitate this, by collaboration between the DOI Foundation 
and the relevant registry 
Where such collaboration is agreed, new potential may be unlocked: the ISBN-A appli- 
cation is an example of the linkage of DOI names to an existing registry. For more infor- 
mation, see DOI System and the ISBN System". 


1.10.5 SERVICE FLEXIBILITY AND EXTENSIBILITY 


The DOI System supports any type of physical, digital or abstract entities, and of hierar- 
chies and relationships between entities. 

Through its scalable architecture, the DOI System is able to handle very large volumes of 
registrations and resolutions of DOI names. In fact, the DOI System is made up of Local 
Handle Services (LHS) of the Handle System (an LHS manages the DOI names under one or 


1 https:/ /www.doi.org/factsheets/ISBN-A.html 
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several prefixes): each LHS may be replicated into multiple service sites and each service 
site may consist of multiple computers (servers). It means that service requests targeted at 
any LHS can be distributed into different service sites, and into different servers within any 
service site. 


1.10.6 PROTECTED AND TRUSTED INFORMATION 


The Handle System - which is used for identification and resolution of DOI names - provides 
client and server authentication, data confidentiality and integrity, and non-repudiation 
based on Public Key Infrastructure (PKI): 


e Any exchanged information between a client and a server of the Handle System can be 
encrypted using a session key. 


e To ensure non-repudiation, clients may request digitally signed responses from any 
server. 


e User access control is supported at DOI record and record element levels. 
Resolution requests for confidential data, as well as any administration requests (for ex- 
ample, creating or modifying a DOI record) require authentication of the user for proper 
authorization. 


e The integrity of a DOI record's data is ensured by signing the DOI record. 
The digital signature is stored in the DOI record itself and can be validated through a 
chain of trust. 


1.10.7 INFORMATION TRACEABILITY 


Traceability is not provided by the DOI System but can be made available through the Digi- 
tal Object Architecture (DOA) on which the Handle System is based (more precisely, 
through the DOA's Digital Object Interface Protocol (DOIP)). 


Different actors may interact with the Digital Object (DO) (which represents the referent) 

throughout its life cycle. Each action is tracked in the DO itself and this information can be 
processed for various applications. For example, in the movie industry, this allows provid- 
ing digital revenue reporting as well as detailed consumption metrics for individual assets. 


1.11 APPLICATION EXAMPLES OF THE DOI SYSTEM 


Many millions of DOI names have been assigned to date, through a growing federation of 

Registration Agencies worldwide. For example: 

e Crossref manages DOI names for the scientific publishing industry. Its application is used 
by publishers and societies to enable cross-citation of scholarly publications. 

e DataCite provides DOI name services for referencing and sharing research outputs and 
resources, primarily research data sets, text and samples. 

e The Entertainment ID Registry (EIDR) provides identifiers and associated metadata that 
are used in the commercial film and video industry, from post-production through broad- 
cast, digital distribution, and reporting. 
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e The British Standards Institution (BSI) Identify uses DOI names in building construction 
projects to identify the products used in the buildings (interior furnishing, lighting, etc.) 
and manage their supply chain information. 


For more information, see Registration Agencies - Areas of Coverage’’. 


12 https:/ /www.doi.org/RA_Coverage.html 
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Chapter 2 


DOI 
GOV 
PART 


This chapter describes the role and functions of the DOI Foundation and of Registration 
Agencies within the DOI System. It also summarizes the policies governing the DOI System 
and explains the policy formulation process. 


In This Chapter 
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2.1 DOI SYSTEM GOVERNANCE BODY: THE DOI FOUNDA- 
TION 


This section describes the status, roles, membership and governance of the DOI Foundation. 


2.1.1 STATUS OF THE DOI FOUNDATION 


The DOI Foundation is a non-stock membership corporation organized and existing under 
and by virtue of the General Corporation Law of the State of Delaware, USA, registered on 
10 October 1997, registration number 2807134 8100. The DOI Foundation's corporate 
registered address is via CT Corporation: The Corporation Trust Company, Corporation 
Trust Center, 1209 Orange Street, Wilmington DE 19801, USA. The Foundation is con- 
trolled by a Board elected by the members of the Foundation. The Corporation is a not-for- 
profit organization, it means prohibited from activities not permitted to be carried on by a 
corporation exempt from US federal income tax under Section 501(c)(6) of the Internal 
Revenue Code of 1986 et seq. The operational address of the Foundation is: The DOI Foun- 
dation, c/o EDitEUR Limited, United House, North Road, London N7 9DP, UK. 


Costs incurred by the DOI Foundation are recouped from operation of the system via a self- 
funding business model. The implementation of the DOI System adds value, but necessarily 
incurs some resource costs in data management, infrastructure provision, and governance, 
all of which contribute to persistence. Persistence is a function of organizations, not technol- 
ogy. 

A Managing Agent is contracted by the DOI Foundation, who represents the DOI Founda- 
tion worldwide, and is responsible for the implementation of policies and management of 
all aspects of the affairs of the DOI Foundation. Functions such as technical operations, le- 
gal and financial services are outsourced. 


2.1.2 OVERVIEW OF THE DOI FOUNDATION ROLES 


The DOI Foundation is the DOI System registration authority and maintenance agency and 
the central body which governs the DOI System. It is the common management and co-ordi- 
nation body for DOI Registration Agencies. It also manages those aspects of the DOI Sys- 
tem that are put through external standardization procedures, as well as those aspects of 
the DOI System that are dealt with through internal policies and procedures. Responsibili- 
ties of the registration authority include: 


e to promote the proper use of the DOI System (and ISO 26324, the ISO specification) 


e to maintain the DOI System technical infrastructure and data in accordance with the 
needs of the users 


e to establish guidelines regarding allocation, registration, maintenance and dissemination 
of DOI names 


e to continuously adapt the DOI Handbook and guidelines to meet the needs of the market 


e to respond to enquiries and information requests related to ISO 26324 in a timely man- 
ner 


e to establish due diligence and quality assurance procedures of the DOI System 
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2.1.3 ISO 26324 REGISTRATION AUTHORITY 


The DOI Foundation is the ISO 26324 Registration Authority, governed by an agreement 
between ISO and the Foundation. ISO 26324 specifies the duties of the Registration Au- 
thority: services to be provided and technical duties. 


SERVICES TO BE PROVIDED BY THE REGISTRATION AUTHORITY 
The ISO 26324 Registration Authority shall provide the following services: 


e promote, coordinate and supervise the DOI System in compliance with the specifications 
of this International Standard 


e supply technology and infrastructure for resolution, metadata and registration function- 
ality in compliance with the specifications of this International Standard and ensure that 
any changes in selected technology will be compatible with earlier DOI applications 


e allocate unique DOI prefixes to registrants and maintain an accurate register of the DOI 
prefixes that have been assigned 


e secure the maintenance of DOI names and associated DOI resolution records through the 
maintenance of a single logical directory of all registered DOI names, the DOI directory 


e enable the registration and mapping of DOI metadata through the maintenance of, or 
agreed use of, an appropriate data dictionary 


e implement policies and procedures governing the process of DOI registration, including 
rules to aid persistence of DOI names and interoperability within networks of DOI users 


e develop, maintain and make available documentation for users of the DOI system, in- 
cluding the provision of a User Manual for registrants which shall specify implementation 
details in conformance with this International Standard 


e review relevant technology developments and maintain current information on appropri- 
ate syntax character encoding, resolution software implementations, etc. 


e provide a unifying record for a referent in case multiple DOI names are assigned to the 
same referent (this may happen, for example, through assignment of DOI names by two 
different registrants) 


TECHNICAL DUTIES OF THE REGISTRATION AUTHORITY 
The ISO 26324 Registration Authority shall provide the following technical services by 
means of a User Manual: 


e maintain a list of approved proxy servers (such as https:/ /doi.org/ which resolve DOI 
names in web browsers) 


e provide current information on appropriate encoding of characters 
e provide current information on resolution technology 

e maintain a list of representations used in other schemes 

e provide information on common encodings 


e specify, if required, more constrained rules for the assignment of DOI names to objects 
for services which make use of the DOI System 
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Where specified, these rules shall be compatible with the overall DOI System specifica- 
tion and shall not form part of this International Standard. 


publish rules to aid persistence of identification (for example, requirements for mainte- 
nance of records, default resolution services) 


publish the DOI Kernel Metadata Declaration that specifies the metadata elements for 
each DOI name 


e provide output metadata to support the services of the DOI System 


establish format and schema specifications for input and service metadata declarations 


provide a data dictionary as the repository for all data elements and allowed values 
used in DOI metadata specifications to facilitate interoperability across selected existing 
schemes 


e provide a data dictionary as the repository for all data elements and allowed values (the 
items which may be used as values of each element) used in DOI metadata specifications 

e provide the data dictionary mappings of other relevant schemes, as determined by the 
ISO 26324 Registration Authority (such as ISO codes for territories, currencies and lan- 
guages) 

e specify a set of allowed values of each kernel element 

e specify an XML Schema of the DOI Kernel Metadata Declaration 

e register sets of other metadata elements and sub-elements as needed 


e prevent duplication of a DOI name once registered 


2.1.4 REPRESENTATION TO STRATEGIC ORGANIZATIONS 


A key role of the DOI Foundation is representation to organizations which are of strategic 
importance in the implementation of the DOI System. This includes: 


e participation in governance and continuity activities of the Handle System whose central 
body is the DONA Foundation 
In addition, the DOI Foundation has contractual agreements for provision and persis- 
tence of the Handle System with the DOI technical support service provider (who is cur- 
rently CNRI) 


e maintenance of formal and informal alliances and liaisons with several other organiza- 
tions 
A significant element of the work of the DOI Foundation lies in tracking standards devel- 
opments in related areas, understanding their significance to the context within which the 
DOI System operates, and establishing working relationships with the responsible organ- 
izations and projects to ensure that appropriate co-operation is fostered to mutual bene- 
fit and that parallel developments do not remain in ignorance of one another. 


e role as the formal Registration Authority of the ISO/IEC MPEG21 Rights Data Dictionary 
This standard is not a requirement for DOI System use. For further information, send 
questions to info@doi.org. 
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2.1.5 DOI FOUNDATION MEMBERSHIP 


The activities of the foundation are controlled by its members, operating under a legal 
Charter and formal By-laws. Membership is open to all organizations with an interest in 
digital network publishing, content distribution, rights management, and related enabling 
technologies. 


MEMBERSHIP OBLIGATIONS 


By participating in membership of the DOI Foundation, members agree to: 

e support the goals of the DOI Foundation, which ensure that the DOI System is an interna- 
tionally adopted standard for digital object identification 

e participate in the activities of the DOI Foundation 

e comply with the Foundation's By laws, Agreements and Policies as these may be updated 
from time to time 

e restrict access to the password-controlled portions of the Foundation's web site to mem- 
bers of the Foundation 


e adopt the DOI brand identity 
The DOI Foundation provides members with the current identity information and with 
marketing materials. 

e add the DOI Foundation to the circulation of all their press releases and news announce- 
ments, and notify the Foundation of forthcoming relevant events and activities 
Selected news about members' DOI activities may be carried on the DOI News page, 
with a link to the original announcement. 


MEMBERSHIP CLASSES 


There are four classes of membership: 


e General Membership 
This membership is offered to any organization supporting the development of the DOI 


System that is not a Registration Agency. It is subject to a signed agreement’. 

General membership is a pre-requisite for any organization applying to become a Regis- 
tration Agency. If a General Member subsequently is appointed as a Registration 
Agency, their membership transfers from the General to the RA category. 


e Registration Agency Membership 
This membership is only available to organizations who have successfully undergone the 
process of becoming a Registration Agency (RA) (see 2.2.5). 
The primary role of RAs is to provide services and applications to registrants by allocat- 
ing DOI prefixes, registering DOI names and providing the necessary infrastructure to 
allow registrants to declare and maintain DOI metadata and DOI records. For more in- 
formation about RAs, see 2.2. 


'S https: / / www.doi.org/resources/ GeneralMemberAgreement.pdf 
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e Charter Membership 
This membership was initially established for founding the DOI Foundation and is only 
offered to organizations whose main activities are in the creation or production and dis- 
semination of intellectual property. The DOI Board reserves the right to determine eligi- 
bility for the Charter membership category. 


e Affiliate Membership 
This membership is restricted to professional associations who have one or more of their 
current members in current membership of the DOI Foundation. Organizations outside 
this scope may be invited or admitted at the Board's sole discretion. Affiliate membership 
does not carry voting rights, and Affiliate members are not eligible for Board member- 
ship. Registration Agencies are not eligible for this category of membership. 


General, Registration Agency and Charter members are entitled to vote in annual DOI 
Foundation's elections within their own category of membership (There are no differences in 
member rights and benefits between Charter and General.). Affiliate membership does not 
carry voting rights. 


More information is available on the membership classes on the DOI web site 4. 


MEMBERSHIP FEES 


This paragraph describes general statements about DOI Foundation membership fees. 
The following rules apply: 
e Membership fall due annually on the anniversary of joining. 
e Membership reduction may be applied as follows: 
o General membership fee may be reduced at the sole discretion of the DOI Board. 


o Registration Agency membership fee is included as part of operational fees, allocated 
annually on a cost-sharing model (see 2.2.6). 
e Criteria which will be considered for fee reduction include, in particular, any of the fol- 
lowing: 
o organizations with a significant role in the creation or ongoing support of the DOI 
Foundation 
o not-for-profit organizations, depending on their annual revenue 
o for-profit organizations, depending on their annual revenue and other criteria 
e If a General member subsequently is appointed as a Registration Agency (RA), their 
membership transfers from the General to the RA category, and any unexpired portion of 
the previous General membership fee is credited to their RA membership dues. 


NOTE In general, it is likely that the cost of fees will be deductible as a business expense of the 
joining entity. The detailed question of deductibility is, however, a matter for the tax advisors of 
the entity that is joining, and it is not governed by DOI Foundation's status as a not-for-profit en- 
tity. 


14 https:/ /www.doi.org/the-community / who-are-the-members-and-users 
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MEMBER STRATEGY MEETINGS 


Strategy meetings of the DOI Foundation members are held at least once a year, and usu- 
ally one in mid-year and one at the end of the year, and are open to all members and non- 
member guests (by invitation only). Members are advised of forthcoming meetings by email. 


DOI REPRESENTATIVE OF A MEMBER ORGANIZATION 


Each member organization of the DOI Foundation must provide one named DOI repre- 
sentative, who will be responsible for the DOI matters. In particular, the DOI representative 
will represent the organization at all Board meetings and in voting issues. Members must en- 
sure that the DOI Foundation is kept informed of any representative changes. Should the in- 
dividual leave the member organization, or step down from the representation role, the or- 
ganization will name a replacement. 


Additional persons from the member organization may participate in all DOI activities. 


TRIAL PREFIX 


On joining the DOI Foundation, a unique DOI prefix is available for experimental purposes 
for each member. The number of DOI names allocated with this experimental prefix will be 
subject to review and may be limited at the discretion of the DOI Foundation. If further DOI 
prefixes are required for non-experimental purposes, members must work with one of the 
Registration Agency members. Trial prefix use is particularly intended for those members 
wishing to develop applications and move to later Registration Agency status. 


Contact the DOI technical support service provider (doi-admin@doi.org) to request one, 
and discuss possible usage. 


2.1.6 DOI FOUNDATION GOVERNANCE 


The DOI Foundation is governed by its members, through an elected Board. 


BOARD OF DIRECTORS 

The Board is responsible for all aspects of management of the DOI System, including policy 
formulation and standards maintenance. 

The Board consists of: 

e Board officers: a Chair, Vice Chair, and Treasurer, each elected from the Board 


e Board members 
Members of the DOI Foundation become Board members according to the following 
rules: 


o All Charter members are automatically members of the Board. 


o All Registration Agency (RA) members are automatically members of the Board after 
one full year of RA membership 


o General members are represented by one seat on the Board held for a three-year 
term, nominated from amongst the existing General members. Procedures for election 
in the event of more than one nomination are defined in the By-Laws. 


o Affiliate Members are not represented on the Board. 
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The Board reviews the number and distribution of Board seats from time to time. 


NOTE The members of the Board are not remunerated for their services to the DOI Foundation. 


EXECUTIVE COMMITTEE 


The Executive Committee is a subcommittee of the Board, elected by the Board, consisting 
of not fewer than three Directors and chaired by the Chairman of the Board. It may meet 

between Board meetings to deal with matters not requiring a meeting of the full Board, or 
requiring urgent discussion. In practice, the Executive Committee normally consists of the 

Chair, Vice Chair and Treasurer. 


MANAGING AGENT 


The Board of Directors of the DOI Foundation appoints a Managing Agent responsible for 
managing the DOI Foundation and carrying out policy formulated by the Foundation. 


BOARD MEETINGS 


The Board meets regularly. Issues which any member feels should be considered by the 
Board should first be brought to the attention of the Managing Agent or a Board member. 
Board meetings are open to all members who may attend as observers and participate but 
not vote, except for designated closed Executive Sessions. 


The DOI representative of each organization will represent the organization at all Board 
meetings and in voting issues. Substitution of another individual from the organization at 
Board meetings is possible by advance agreement of the Chair of the Board. 


2.2 DOI SYSTEM PARTICIPANTS: REGISTRATION AGENCIES 
AND REGISTRANTS 


A Registration Agency (RA) (formally called Registration Agency Member) can be consid- 
ered as a module of the DOI System, serving a constituency. New RAs can be added at any 
time, thereby allowing modular growth of the system by adding new communities of users 
and providing tailored services for them. A registrant is a person or organization who has 
requested and received the registration of a particular DOI name. 


This section explains the role and function of Registration Agencies in the DOI System, in- 
cluding operational and technical requirements and policies. A list of current Registration 
Agencies and their areas of coverage is available on the DOI web site’. 


2.2.1 ROLES OF A REGISTRATION AGENCY 


A Registration Agency (RA) provides services to one or several communities of users. A 
community is loosely defined, but could be any group of parties sharing a common applica- 
tion or interest, under any organizational structures (public, private sector, not-for profit, 
regulator, etc). 


15 https:/ / www.doi.org/registration_agencies.html 
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The services an RA provides to their users include: 
e allocating prefixes 


e registering DOI names and providing the necessary infrastructure to allow registrants to 
declare and maintain DOI metadata and DOI record (in other words, use of the DOI Sys- 
tem) 


e services not directly involving the DOI System which add value, for example: manage- 
ment of a database of related data with facilities for look-up from metadata to DOI name 

The role of an RA could also encompass any of the following activities: 

e providing information and advice to the community 

e providing applications, services, marketing, outreach, business cases etc. to introduce 
the DOI System to the community 

e designing and implementing specific operational processes, for example: quality control 
of input data and output data 


e integrating the community into other DOI related activities and services 


2.2.2 BUSINESS MODEL FOR REGISTRATION AGENCIES 


Registration Agencies (RA) must comply with the policies and technical standards estab- 
lished by the DOI Foundation, but are free to develop their own business model for running 
their businesses. There is no appropriate "one size fits all" model. RAs may be of any form 
(commercial, governmental, or not for profit). Examples of the functions of an organization 
which might become an RA include, but are not limited to: 


e An organization is running a registry (of identifiers and related data) and wishes to add 
DOI functionality and services to its existing services. 


e An existing aggregator of information wishes to use DOls to improve their services and 
add new features. 


e A new initiative is launched in a defined sector to meet specific needs or solve a prob- 
lem, for example, an industry collaboration or effort to solve a common problem (exam- 
ples of these including Crossref, DataCite and EIDR are amongst the most successful ex- 
isting RAs). 

e A start-up which has a business model suggesting a novel DOI application might be fruit- 
ful: in view of the importance of persistence, this is likely to require significant guaran- 
tees of continuity planning. 


The costs of providing DOI registration may be included in the services offered by an RA 
provision and not separately distinguished from these. Examples of possible business mod- 
els may involve: 


e explicit charging based on the number of prefixes allocated or the number of DOI names 
allocated 


e volume discounts, usage discounts, stepped charges, or any mix of these 


e indirect charging through inclusion of the basic registration functions in related value 
added services 


e cross-subsidy from other sources 
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Operational costs of the system are borne directly or indirectly by the registrants. The busi- 
ness model adopted by an individual RA is a matter for the RA alone, provided that it com- 
plies with the DOI Foundation's policies. 


NOTE RAs may choose to provide other DOI System-related services to registrants, without limita- 
tion as long as they conform with DOI agreements and policies. These services may include any 
combination of value added services in, for example, data, content or rights management. RAs 
may also develop services that exploit the metadata that they collect. 


RAs will typically register many thousands or millions of DOI names, and have multiple cus- 
tomers and services, thereby generating economies of scale. RAs for smaller scale applica- 
tions will probably not be viable as stand-alone entities, though RAs may collaborate, for 
example to share back-office services to improve viability. Communities that cannot identify 
an acceptable RA should contact the DOI Foundation to discuss how the DOI System might 
be used, and whether a new RA application might be developed. 


NOTE Once a DOI name is assigned, anyone may resolve that DOI name without charge. At least 
some information will always be available on resolution. 


2.2.3 SERVICE NON-EXCLUSIVITY AND COMPETITION MATTERS 


Exclusivity of DOI name registration rights covering either a specific geographic territory or 
a wide area of application in general (for example, audio) will not normally be granted to 
any Registration Agency (RA). Exceptions are possible, for example where the RA is man- 
dated to operate as a service for an existing closed community and will not offer their regis- 
tration services outside that community. DOI applications often overlap and in the digital 
world any number of categorisations are possible, which makes exclusive arrangements dif- 
ficult. The only exception at present is an implementation for the Publications Office of the 
EU, covering DOI registration and management of official EU documents. 


In order to maintain a persistent identifier, a DOI application normally provides more value 
than simply registering a DOI, by offering an added value service such as citation linking or 
metadata management. RAs operate as independent businesses on the basis of these 
added-value services and unique selling propositions they bring to offer to the market. In 
order to provide some coherence of DOI services, applications to become an RA are as- 
sessed in the context of likely business implications. Where there is an overlap of the ex- 
pected market or services of RAs, each will be informed of the potential for overlap or com- 
petition and invited to address the problem in such a way as to encourage uptake of the 
DOI System as a whole whilst ensuring that legitimate business interests are met. 


2.2.4 RA AGREEMENT 


Registration Agencies (RA) enter into an agreement with the DOI Foundation. A copy of this 
generic agreement is available on the DOI web site (see RA Agreement'*). 


16 https:/ /www.doi.org/resources/ Master-DOI-Foundation-Agreement.pdf 
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The RA agreement covers a number of areas including: 
1. Rights granted to the RA: 


o appointment as an RA having the authority to assign DOI names as part of the 
DOI System using the DOI prefix or prefixes that have been assigned to RA by the 
DOI Foundation 


o nonexclusive right and license to use DOI trademarks 


o sub-licenses to exercise all rights in the implementation technologies (such as the 
Handle System) required for the fulfillment of RA's rights and obligations as an RA 
under the DOI System 


2. Obligations of the RA: 


o remain a fully paid member of the DOI Foundation, including adherence to all 
DOI agreements and policies 


o provide registration services and infrastructure 

o adopt procedures to assure quality 

o respect rights of other RAs 
3. Obligations of the DOI Foundation: 

o maintain the DOI System, infrastructure and documentation 

o cooperate with RAs in setting policies and fees regarding RAs 

o participate in ISO and other relevant standards-setting bodies 
4. Rights and intellectual property: 


o The DOI Foundation has the exclusive right to appoint RAs and to be the Registra- 
tion Authority of ISO 26324. 


o Trademarks remain the property of DOI Foundation and are licensed to RAs. 


o RAs may assert patent or other proprietary rights in the RA services, but must com- 
ply with the DOI Patent and Trademark Policies. 


o Inthe event of the DOI Foundation ceasing to be the Registration Authority of ISO 
26324, continuity must be ensured. 


5. Change procedures, warranties, indemnities, and liability 
6. Termination procedures, including: 


o considerations in the event of an RA leaving the DOI Foundation (for example, the 
transfer of registered DOI names to a successor) 


o considerations in the event of the DOI Foundation being unable to continue (for 
example, the orderly transition of the responsibilities of the DOI Foundation to a 
successor) 


2.2.5 PROCESS OF BECOMING A REGISTRATION AGENCY 


To become a Registration Agency (RA), an organization must: 


1. become a General Member of the DOI Foundation 
Organizations interested in becoming a General Member of the DOI Foundation with a 
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view to developing an RA application are encouraged to contact the DOI Foundation for 
an exploratory discussion. See also the detailed DOI membership information in 2.1.5. 


2. have made a successful application to the DOI Board to be appointed as an RA 
All appointments as an RA are made at the discretion of the Board of the Foundation. It is 
unlikely that an application simply to register DOI names without offering additional ser- 
vices utilising these registered DOI names will be acceptable or successful. Potential ap- 
plicants are strongly encouraged to review one or more of the existing RAs for examples 
of services and operations. See also 2.2.2. 


3. sign an RA Agreement with the DOI Foundation: see 2.2.4 


2.2.6 FEE STRUCTURE FOR REGISTRATION AGENCIES 


The DOI System is a cost-recovery system. ISO Council resolution 17/2012 "approves that 
fees can be charged on a cost-recovery basis by the DOI Foundation in the operation of the 
Registration Authority for ISO 26324". The cost of common DOI infrastructure (managed 
by the DOI Foundation on behalf of all Registration Agencies) is met by a charge made to 
each Registration Agency, whilst allowing each Registration Agency to adopt individual 
commercial models incorporating DOI name registration for their services. 


2.2.7 REGISTRANT ROLES AND DUTIES 


A registrant can be any individual or organization who wishes to uniquely identify entities 
using the DOI System. 


A registrant: 


e registers DOI names with a Registration Agency (RA) 
If a registrant has multiple types of content or application requirements, it may choose to 
use several RAs to provide services. 


e ensures appropriate content management of their own material (maintenance of URLs 
and data), either directly or by contract (for example, with the RA) 


e has an agreed relationship as a customer or client of an RA 


e does not need to be a member of the DOI Foundation 


2.3 DOI SYSTEM GOVERNING POLICIES 


This section introduces the policies governing the DOI System. 


2.3.1 POLICY FORMULATION PROCESS 


Policies are developed within the context of the DOI Foundation's By-laws and Charter. 
Within this scope, formal agreements are in place between the DOI Foundation and its part- 
ners. Individual policies are then defined consistent with these agreements. 


Policy development takes place through discussion at regular strategy and members meet- 
ings of the DOI Foundation, and sometimes through working groups tasked with reviewing 
specific areas. All proposed changes in the Core Specification or policies will be presented 
initially to the RA Working Group (RAWG) for discussion and approval under such quorum 
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and voting procedures as may be agreed by the RAWG members. Changes approved by 
the RAWG must then be approved by the DOI Foundation's Board. 


2.3.2 LIST OF FORMAL DOI DOCUMENTS 


The table below lists the approved policies and agreements governing the DOI System. 
NOTE Policies are binding on all members of the DOI Foundation. 
Table 2 Formal DOI documents 


Antitrust policy The DOI Foundation conducts their operations in strict compliance | Antitrust Policy” 
with the antitrust laws, regulations and guidelines of all jurisdic- 
tions where the Foundation conducts meetings, programs, or ac- 
tivities. 
Conflict of interest | This policy protects the interests of the DOI Foundation when itis | Conflict of Inter- 
policy contemplating entering into a transaction or arrangement that est Policy'® 
might benefit the private interest of a Director or Officer of the 
Foundation. 


Trademark policy | Guidelines for use of the trademarks which the International DOI | Trademark Pol- 
Foundation owns. DOI®, DOI>®, DOI.ORG® and shortDOI® are icy”? 
registered trademarks of the International DOI® Foundation. 
Patent policy Procedures relating to patent rights and claims among Registra- RA Patent Pol- 
tion Agencies (RA): to enable the DOI System to be available to | icy” 
all who want to use it on equal terms; to preserve and protect the 
collective investment in the DOI System and standard; and to al- 
low RAs to develop added-value services and features. The DOI 
Foundation does not itself hold any patent rights in the DOI Sys- 
tem. 


Data polic This policy concerns confidentiality of data such as usage statistics | Data Policy?! 
policy policy y g Vata Folicy 
and information about individual DOI name resolution, for the 
DOI Foundation and the Registration Agencies. 


RA collaboration | General requirements and procedures for resolving conflicts be- | Collaboration 


policy tween Registration Agencies and encouraging collaboration, to Policy”? 
the benefit of the DOI community. 


DOI Proxy imple- | Requirements for support and functionality of proxy servers by Proxy Policies?’ 
mentation policy | Registration Agencies, including those running instances of the 

DOI Proxy Server and their own local proxies, and support for 

the Default Proxy and the functionality of the Default Proxy. 


17 https:/ /www.doi.org/resources/ Antitrust_Policy.pdf 

18 https:/ /www.doi.org/resources/Conflict_of_Interest_Policy.pdf 

1? https:/ /www.doi.org/resources/ 130718-trademark-policy.pdf 

20 https: / /www.doi.org/resources/RAPatentPolicy.pdf 

21 https:/ /www.doi.org/resources/|IDF_DataPolicyv3.pdf 

22 https:/ /www.doi.org/resources/IDF_RA_CollaborationPolicyv3.pdf 
2 https:/ /www.doi.org/resources/proxy_policies. html 
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Core specification 


Suspension and 
termination of an 


RA 


General Member 
Agreement 


Registration 
Agency Agree- 
ment 


ISO 26324: In- 
formation and 
documentation — 
Digital object 
identifier system 


A technical specification relating to the description of the DOI 
System covered in the DOI Foundation's Registration Agency 
Agreement. 

This document outlines procedures for dealing with DOI names in 
the event of suspension or termination of an RA. 


This agreement governs the terms and conditions under which a 
General Member of the DOI Foundation agrees to participate in 
the DOI Foundation and use the DOI System. 

This agreement governs the relationship between a Registration 
Agency (RA) and the DOI Foundation. The RA agreement pro- 
vides equal terms to each RA, unless specific waivers or excep- 
tions have been agreed to meet the needs of a specific commu- 
nity. 

ISO 26324 specifies the syntax, description and resolution func- 
tional components of the digital object identifier system, and the 
general principles for the creation, registration and administration 
of DOI names. 


DOI Core Speci- 
fication”4 


RA Suspension 


and Termination 


Procedures? 


General Mem- 


ber Agreement’ 


RA Agreement” 


24 https://www.doi.org/resources/DOICoreSpecificationvl.pdf 

25 https://www.doi.org/resources/RA_Termination.pdf 

26 https:/ /www.doi.org/resources/ GeneralMemberAgreement.pdf 
7 https://www.doi.org/resources/ 160101RA_Agreement.pdf 
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Chapter 3 


DOI 


This chapter defines the syntax for a DOI name. It also explains the DOI name assignment 
principles and how other identifier schemes can be integrated into the DOI system. 


For information about the definition of prefix allocation and suffix naming policies, see 
Chapter 8. 


In This Chapter 


3.1 Assignment Principles of the DOI Name 5,..:25<ccccssasnceecenancasvesseadestancees seco niassannceccsenosaseseaies 42 
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3.1 ASSIGNMENT PRINCIPLES OF THE DOI NAME 


The following principles for assigning DOI names apply: 


e A DOI name can be assigned to any object whenever there is a functional need to distin- 
guish it from other objects. 
DOI names can be assigned at any desired degree of precision and granularity that a 
Registration Agency deems to be appropriate based on the needs of their community. 


e Each DOI name shall specify one and only one referent in the DOI System. 


e The assignment of a DOI name requires that the registrant provide metadata describing 
the object to which the DOI name is being assigned. The metadata shall describe the ob- 
ject to the degree that is necessary to distinguish it as a separate entity within the DOI 
System. 


e No time limit for the existence of a DOI name shall be assumed in any assignment (see 
1.9). 


e A DOI name shall not be used as a replacement for other ISO identifier schemes. 


NOTE While a referent can be specified by more than one DOI name, it is usually recommended 
that each referent has only one DOI name. But depending on the DOI application, there may be 
legitimate reasons to assign multiple DOls to the same referent. 


3.2 SYNTAX OF THE DOI NAME 
The syntax of the DOI name is standardized as part of ISO 26324. 


3.2.1 GENERAL CHARACTERISTICS OF THE DOI SYNTAX 


The DOI syntax shall be made up of a DOI prefix and a DOI suffix separated by a forward 
slash. 


There is no defined limit on the length of the DOI name, or of the DOI prefix or DOI suffix. 


The DOI name is case-insensitive and can incorporate any printable characters from the le- 
gal graphic characters of Unicode. Further constraints on character use (for example, use 
of language-specific alphanumeric characters) can be defined for an application by the ISO 
26324 Registration Authority. 


NOTE The exact definition of case-insensitivity is expected to be clarified in an upcoming revision 
of the International Standard. 


The DOI name is an opaque string for the purposes of the DOI system. No definitive infor- 
mation may be inferred from the specific character string of a DOI name. In particular, the 
inclusion in a DOI name of any registrant code allocated to a specific registrant does not 
provide evidence of the ownership of rights or current management responsibility of any in- 
tellectual property in the referent. Such information may be asserted in the associated 
metadata. 
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3.2.2 DOI PREFIX 


The DOI prefix refers to the DOI namespace (a namespace is allocated to a given service 

provider): see 1.7.4. 

The DOI prefix is <directorylndicator>.<registrantCode>. 

The following rules apply: 

e The directory indicator can contain only numeric values. The directory indicator is usually 
10 but other indicators may be designated as compliant by the DOI Foundation. 


e The registrant code can contain only numeric values and one or several full stops which 
are used to subdivide the code. For example: 10.1000, 10.500.100, etc. 
If the directory indicator is 10 then a registrant code is mandatory. 


3.2.3 DOI SUFFIX 


Each suffix shall be unique to the prefix element that precedes it. The unique suffix can be a 
sequential number, or it might incorporate an identifier generated from or based on an- 
other system used by the registrant (for example, ISAN, ISBN, ISRC, ISSN, ISTC, ISNI; in 
such cases, a preferred construction for such a suffix can be specified, as in Example 2). No 
length limit is set to the suffix by the DOI System. 


See also 8.3. 


EXAMPLES 


e Example 1 
10.1000/123456: DOI name with the DOI prefix "10.1000" and the DOI suffix 
"123456" 

e Example 2 
10.1038/issn.1476-4687: DOI suffix using an ISSN 
To construct a DOI suffix using an ISSN, precede the ISSN (including the hyphen) with 
the lowercase letters "issn" and a period, as in this hypothetical example of a DOI name 
for the electronic version of the scientific journal Nature. 


3.2.4 CHARACTER SET SUPPORTED IN THE DOI NAME 


DOI Names may incorporate any printable characters from the Universal Character Set 
(UCS) of ISO/IEC 10646, which is the character set defined by Unicode. The Handle Sys- 
tem at its core uses UTF-8, which is a Unicode implementation and so in its pure form has no 
character set constraints at all: any character can be sent to, stored in, and retrieved from a 
Handle server. 


The character set encompasses most characters used in every major language written today 
(see also 10.2.1). 


NOTE Some characters should be avoided: see 3.4. 


3.2.5 CASE INSENSITIVITY OF THE DOI NAME 


DOI names are case insensitive, using ASCII case folding for comparison of text. (Case in- 
sensitivity for DOI names applies only to ASCII characters. DOI names which differ in the 
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case of non-ASCII Unicode characters may be different identifiers.) 10.123 / ABC is identi- 
cal to 10.123/AbC. All DOI names are converted to upper case upon registration, which is 
a common practice for making any kind of service case insensitive. The same is true with 
resolution. If a DOI name were registered as 10.123/ABC, then 10.123/abc will resolve 
it and an attempt to register 10.123/AbC would be rejected with the error message that 
this DOI name already existed. 


Although from a character encoding viewpoint suffixes are case sensitive, for example 
10.123/ABC is different from 10.123/AbC and the two could be distinguished as different 
identifiers, the DOI Foundation decided to remove case sensitivity, after a detailed review 
of the consequences. The Handle System is configurable by service so as to be either case 
sensitive or case insensitive and therefore allows this. This restriction has been implemented 
from an early stage, and Registration Agencies have not introduced any cases of two DOI 
names distinguishable only by ASCII case resolving to the same thing. 


The advantages of case sensitivity (librarian and publisher practice, human readability and 
expectations) were outweighed by considerations of data integrity. Case sensitivity practice 
across Internet applications varies: DNS is not, the rest of URLs are except sometimes they 
aren't (this depends on the server), Unix vs PC/Mac file names (Microsoft Windows in gen- 
eral is not case-sensitive, Unix operating systems are always case sensitive), markup lan- 
guage tags, etc. can all cause unexpected problems and one cannot guarantee that any 
particular piece of software will respect case sensitivity and not conflate two DOI names in- 
tended to be different. Some search engines and directories are partially case sensitive. Dif- 
ferent web browsers may differ in case sensitive handling (web browser developers have 
advised that "authors should not rely on case-sensitivity as a way of creating distinct identi- 
fiers, unless they are designing solely for a truly standards-compliant browser"). 


This argued in favor of case insensitivity being the safer, and more robust, option for future 
evolution and development of the DOI System. 


3.2.6 CONSIDERATIONS ABOUT THE USE OF CHECK DIGITS IN DOI 
NAMES 


A DOI name is an opaque string. The DOI System does not itself make use of check digits. 
This is deliberate, for a number of reasons: 


e ability to include an existing identifier string as a prefix in a DOI without any alteration: 
some common strings like ISO identifiers already have a check digit in them which act as 
aids to readability or keyboard data entry in the absence of any automated protocol cor- 
rection; 

e performance considerations if a check sum is calculated at each resolution; 

e identifier schemes such as URL have no check digit: the underlying TCP/IP protocol they 
use has an error-correction component. This aids creation and use. 

However, other applications may make use of check digits, so a checksum digit may be in- 

serted into a DOI name if it would be useful for some other application. Use of checksums in 

a particular DOI System application can be introduced as a rule of that application by the 

Registration Agency concerned. An example is the EIDR application, where the check char- 
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acter is computed only over the DOI suffix. It does not include the prefix because if the pre- 
fix is wrong, it is highly probable that the DOI name will go to an incorrect resolution sys- 
tem anyway. The EIDR registry separately validates the prefix of any DOI name sent 
through its API. 


3.3 PRESENTATION FORMATS OF A DOI NAME 


A DOI name should be preceded by a lowercase "doi:" unless the context clearly indicates 
that a DOI name is implied. The "doi:" label is not part of the DOI name value. For exam- 
ple, the DOI name "10.1006/jmbi.1998.2354" is displayed and printed as 
"doi:10.1006/jmbi.1998.2354". This representation complies with the syntax f the IETF 
specification, RFC 3986, for a representation as a URI (Uniform Resource Identifier), in the 
same way as "ftp:" and "http:". 

In a print version, to let the readers know that the DOI name is actionable, Registration 
Agencies may elect to print the DOI Proxy URL form (see 1.5.1). It is then advantageous to 
use some convention of showing both the plain DOI name and a way to resolve it online (a 
shorthand way of saying "the DOI name for this article is 10.1002/prot.999 and current 
information may be found on the web through https:/ / doi.org/ 10.1002/prot.999" or 
"available via https:/ /doi.org/..."). 


NOTE Ifthe URL form of a DOI name is represented by a button on a web page, the web browser 
will normally display the full DOI name when the cursor is moved over the button. 


3.3.1 SPECIFIC PRESENTATION FORMATS OF A DOI NAME 


Specific representations may be agreed to meet special technical requirements. For exam- 
ple, the joint ANSI / Society of Cable and Telecommunications Engineers standard "Digital 
Program Insertion Cueing Message for Cable" (SCTE 35:2013) defines (among other 
things) the standard method for cable TV systems to include EIDR DOI names in-band with 
the programs being broadcast. It uses a compact lossless EIDR representation rather than 
the full ASCII DOI string. This also makes use of the resolvability of DOI names, suggesting 
that IDs so carried can be resolved via an out-of-band mechanism to collect more data. 


DOI names may also be presented in a shortened version via the shortDOI service: see 5.5. 


3.4 CONSTRAINTS ON DOI NAME SYNTAX IN SPECIFIC CON- 
TEXTS 


If the DOI name is used in specific application contexts then there may be requirements or 
restrictions on the use of particular characters: 


e When presented as above as an URL (Uniform Resource Locator) with the web proxy ad- 
dress prepended, some characters must be percent encoded (for example, # must be en- 
coded because this character is used in a URL to indicate the beginning of a URL frag- 
ment). 


e Characters which cannot be handled directly in a specific network or reference context, 
or where ambiguity can arise (for example, minus sign, the hyphen, and the en-dash all 
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look similar on the screen but carry different character values) should be avoided or en- 
coded in an appropriate way (for example, for URLs: should be converted to UTF-8 and 
then hex-encoded). 
The Unicode Standard imposes additional constraints on implementations of ISO/IEC 
10646:2020, the Universal multiple-octet coded character set (usually referred to as the 
Universal Character Set, UCS). See Unicode”! for more information. 


3.5 INTEGRATION OF OTHER IDENTIFIER SCHEMES 


A DOI name shall not be used as a replacement for other identifier schemes such as ISAN, 
ISBN, ISRC, ISSN, ISTC, ISNI and other commonly recognized identifiers, but when used 
with them it can enhance the identification functionality provided by those systems with ad- 
ditional DOI System functionality, and thus, provide interoperability with existing identifier 
schemes. 


This section explains the different ways other identifier schemes can be integrated. For more 
considerations about identifier interoperability, see Identifier Interoperability factsheet?’ on 
the DOI web site. 


3.5.1 SPECIFICATION OF ANOTHER IDENTIFIER IN THE DOI 
METADATA 


The existence of other existing identifier(s) for a referent is incorporated into the DOI 
Metadata Kernel Declaration. 


With this requirement, an existing legacy scheme can be used by any automated processes 
which pick up structured metadata from a DOI System service, using the DOI Kernel decla- 
ration of this referent. 


3.5.2 INCORPORATION OF AN EXISTING IDENTIFIER INTO A DOI 
NAME 


An existing identifier scheme can be included in the DOI syntax. 


PURPOSES 


DOI names can incorporate established identifiers (like ISBN, ISAN, ISWC, PII, or any pro- 
prietary identifier) to allow integration with existing systems. Use of DOI name allows ready 
interoperability with existing abstraction identifiers, with associated manifestation identifi- 
ers and other metadata; with rights metadata; and builds on what is practical in each sec- 
tor. 


CONSIDERATIONS TO BE TAKEN INTO ACCOUNT 


Where syntax rules permit the incorporation of an existing identifier from another scheme 
as part of the DOI name, such rules do not form part of ISO 26324 but are documented 


28 https:/ /home.unicode.org 
2 https:/ /www.doi.org/factsheets/Identifier_Interoper.html 
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separately by the registration authority. In such cases, attention is drawn to the following 
points. 


e The same referent shall be denoted by both the DOI name and the included identifier 
string, to the degree that is necessary to distinguish it as a separate entity within each 
identifier scheme. 


e Within the DOI System itself, the DOI name is an opaque string. No definitive infor- 
mation relating to the other identifier scheme should be inferred from the specific charac- 
ter string used for a DOI name, and the DOI name is not guaranteed to be usable in any 
non-DOI applications designed for the other identifier scheme. 


e Specific syntax rules for the incorporation of an existing identifier from another scheme 
shall be maintained by the ISO 26324 Registration Authority. 


EXAMPLES 


Examples 1 and 2 show the incorporation of an ISBN and an ISSN into a DOI name. Other 
agreed syntaxes for integration are also possible. Example 3 shows that the DOI name is 
not a replacement for the other identifier scheme. 


e Example 1 
10.978.86123/45678 shows a possible incorporation of an ISBN (978-86-123-4567- 
8) into a DOI prefix and suffix. 


e Example 2 
10.1038/issn.1476-4687 shows a DOI suffix using an ISSN. 


e Example 3 
10.97812345/99990 is a DOI name. It cannot be validly submitted to an ISBN point- 
of-sale ordering system, or converted to a GS1 bar code for use as an ISBN bar code. It 
does not conform to the ISBN syntax. 
978-12345-99990 is an ISBN. It cannot be validly submitted to a DOI resolution ser- 
vice; it does not conform to the DOI syntax. 
However both identifier strings have the same referent. 


3.5.3 LINKAGE OF DOI NAMES TO ANOTHER REGISTRY 


A business relationship can be built to facilitate the inclusion of another identifier scheme in 
the DOI syntax, by collaboration between the DOI Foundation and the relevant registry. 
Where such collaboration is agreed, new potential may be unlocked: the ISBN-A applica- 
tion is an example of the linkage of DOI names to an existing registry. For more infor- 
mation, see DOI System and the ISBN System®. 


3.5.4 COMPLEMENTATION OF OTHER IDENTIFIER SERVICES 


The DOI System functionality can be offered to complement other identifier services which 
are available through other parties, for example, for the resolution of identifiers in a vari- 
ety of contexts. Services using an identifier can be offered by multiple providers. Rules of 


3° https:/ /www.doi.org/the-identifier/resources/ factsheets /doi-system-and-the-isbn-system 
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certain identifier systems can necessitate the use of only specified preferred service provid- 
ers; in such cases, the application of the identifier shall follow the rules of the relevant reg- 
istration authority. Each registration authority for an identifier scheme retains autonomy in 
determining rules for usage within its own scheme or community. The DOI Foundation main- 
tains current information on agreed specific mechanisms for use with other identifier 
schemes. 
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Chapter 4 


DOI 


This chapter explains the basis for one of the main technical components of the DOI System, 
the DOI data model, and its ability to ensure interoperability of DOI name metadata as- 
signed through metadata schemes. 


In This Chapter 
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4.1 INTRODUCTION TO DOI METADATA 


Without metadata, an identifier is of very little value. Metadata, which may be defined in 
this context as information about an identified referent, provides human beings or machines 
with the data they need to enable them to make use of that identified referent. Metadata 
may include names, identifiers, descriptions, types, classifications, locations, times, meas- 
urements, relationships and any other kind of information related to a referent. 


There are two ways in which every Registration Agency (RA) is bound to deal with 
metadata as illustrated below: 


e An RA will gather input metadata from referent providers (typically, descriptions of the 
referents and associated rights and policies). 


e An RA will need to provide some level of output or service metadata to support DOI sys- 


tem services. 


Registration Agency (RA) 


Metadata 
Registration 
Service 
Metadata 
deposit 


Content 
Rendering 
Service 


0013 


dol 


Service user A 


Figure 9 Input and service metadata 


Input metadata will provide some, but not necessarily all, of the service metadata. 


In some cases, a metadata declaration will itself be a complete DOI System service. 


4.2 METADATA REQUIREMENTS ACCORDING TO ISO 26324 


This section describes the requirements on DOI metadata specified in ISO 26324. 


4.2.1 GENERAL REQUIREMENTS ON METADATA 


According to ISO 26324, the referent shall be described unambiguously and precisely by 
DOI metadata, based on a structured data model that enables the referent of a DOI name 
to be associated with metadata of any desired degree of precision and granularity to sup- 
port identification, description and services associated with a referent. This is designed to 
do the following: 


e promote interoperability within networks of DOI users by enabling independent systems 


to exchange information and initiate actions from each other in transactions involving 
DOI names 
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Since DOI names can be assigned to any type of object, such interoperability can be 
across different types of content (for example, audiovisual, music and text). 


e ensure minimum standards of quality of administration of DOI names by registrants, and 
facilitate the administration of the DOI system as a whole 


4.2.2 REQUIREMENTS ON METADATA FUNCTIONS 

According to ISO 26324, DOI metadata should support the following functions: 

e generic mechanism for handling complex metadata for all different types of intellectual 
property 
For example, instead of treating sound carriers, books, videos, and photographs as fun- 
damentally different things with different (if similar) characteristics, they are all recog- 
nized as creations with different values of the same higher-level attributes, whose 
metadata can be supported in a common environment. 


e interoperability of metadata across applications, with reference to: 


o media (for example, books, serials, audio, audiovisual, software, abstract works, vis- 
val material) 

o functions (for example, cataloguing, discovery, workflow, and rights management) 

o levels of metadata (from simple to complex) 

© semantic barriers 

o linguistic barriers 


e functional granularity, making it possible to identify an object whenever it needs to be 
distinguished 


4.2.3 REQUIREMENTS ON METADATA REGISTRATION 


According to ISO 26324, metadata describing and identifying the referent to which the 
DOI name is being assigned shall be recorded promptly and accurately. In addition: 


e Data elements and allowed values used in DOI metadata declarations shall be placed in 
a repository (data dictionary) to facilitate interoperability across selected existing 
schemes. 


e The metadata shall meet the minimum requirements of the DOI Kernel Metadata Declara- 
tion. 


4.3 DOI DATA MODEL 


The DOI data model consists of a policy and various tools. It can be extended to meet the 
needs of the Registration Agencies. 


4.3.1 DOI DATA MODEL POLICY 


DOI metadata model policy is concerned with the internal management and exchange of 
metadata between Registration Agencies (RA) within the RA network, and is designed to: 


e promote interoperability within the network of DOI system users 
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e ensure minimum standards of quality of administration of DOI names by RAs and facili- 
tate the administration of the DOI System as a whole 


POLICY ON DOI METADATA DECLARATION 


A metadata declaration must be made for every entity identified with a DOI name accord- 
ing to the following principles: 


e The declaration must contain a minimum set of mandatory metadata which is defined 
through the DOI Kernel Schema. This schema is designed to be as limited in scope as 
possible, and it is applicable to any entity identifiable by the DOI System. 


e Additional metadata can be declared. They should be based on an agreed metadata ex- 
change schema if metadata interoperability is required with other Registration Agencies 
(RA). 

e All declared DOI metadata is based on an underlying ontology through the DOI Kernel 
Schema which specifies all data elements and allowed values. 


DOI data model policy places no restrictions on the form and content of input and service 
metadata declarations of a Registration Agency (RA), except insofar as input metadata 
must support the minimum requirements implicit in the DOI Kernel. RAs may specify their 
own metadata schemes and messages, or use any existing schemes in whole or part for 
their input and service metadata declarations. 


POLICY ON DOI NAME ADMINISTRATION 


The second aim of DOI data model policy is to ensure minimum standards of quality of ad- 
ministration of DOI names by Registration Agencies (RA), and facilitate the administration 
of the DOI System as a whole. This aim may also be seen as supporting the first aim of in- 
teroperability, but it specifically addresses the need to ensure that a prospective RA is com- 
petent to issue DOI names responsibly and that ambiguous DOI names do not enter the net- 
work. 

The policy provides a simple test of an RA's competence: the ability to make a DOI Kernel 
Declaration, which requires that the RA has an internal system which can support the unam- 
biguous allocation of a DOI name, and is fundamentally sound enough to support interop- 
erability within the network. In addition, the policy requires that RAs maintain a record of 
the date of allocation of a DOI name, and the identity of the registrant on whose behalf the 
DOI name was allocated. 

The DOI data model policy also exists to support the future development of mechanisms for 
facilitating the administration of the DOI System as a whole. This might be done, for exam- 
ple, through the use of terms registered in the DOI Kernel Schema as types, to classify DOI 
names, or services. 


4.3.2 DOI KERNEL METADATA 


The assignment of a DOI name requires that the registrant provide metadata describing the 
object to which the DOI name is being assigned. At minimum, this metadata shall consist of 
a DOI Kernel Metadata Declaration. 


The DOI Kernel is specified through the DOI Kernel Schema (see 10.1). 
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BASIC INFORMATION CONTAINED IN THE DOI KERNEL 


The DOI Kernel Metadata Declaration should answer basic questions such as: 
e What is the DOI name assigned to the referent? 

e ls the referent commonly referenced with another identifier? 

e What is the referent usually called? 

e What is the primary type of the referent (examples: creation, party, event)? 


e What is the structural type of the referent (for example, for a creation: physical, digital, 
performance, abstraction)? 


It answers other questions about the referent depending on the primary type of the referent, 
and the following administrative questions: 


e Which Registration Agency issued this DOI name? 
e When was the declaration issued? 
e Which Kernel version is it? 


The data elements of the Kernel are specified by the DOI Kernel Schema (see 10.1 for more 
information). 


NOTE Registration Agencies can add new values to open lists of allowed values of the DOI Kernel: 


see 4.3.6. 


PURPOSE OF THE DOI KERNEL 


The purpose of the DOI Kernel is to allow: 


e recognition 
Recognition in this context means that the Kernel metadata should be sufficient to show 
clearly what kind of thing which is the DOI referent (by various classifications), and al- 
low a user to identify with reasonable accuracy the particular thing (by various names, 
identifiers and relationships). These two are complementary, for it is possible to know 
that something is (for example) a movie or a DVD without knowing that it is "Casa- 
blanca", and vice versa. Recognition is required for the discovery of referents, and also 
to provide information to a user when a referent is discovered, whether by intent or acci- 
dent. The user of metadata may be a person or a machine. The structure of the Kernel is 
often but not always sufficient to provide a unique description of a referent (disambigua- 
tion), and further specialized metadata elements may be required in some cases. A 
unique description can in fact always be achieved by adding additional descriptive text 
to a referent, but this is not a satisfactory way if the additional text is being used in place 
of a formal classification, measurement, identifier, time or other structured contextual 
metadata, as it undermines the second goal of interoperability. 


e interoperability 
Interoperability in this context means that Kernel metadata from different DOI Registra- 
tion Agencies may be combined or queried by the same software without requiring se- 
mantic mapping or transformation. Interoperability is achieved when data elements or 
their values are common to diverse metadata schemas. The Kernel provides this directly 
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by mandating a common set of core elements and classifications, but this of course sup- 
ports only limited interoperability. 


4.3.3 ADDITIONAL METADATA 


Additional metadata can be declared. They should be based on an agreed metadata ex- 
change schema if metadata interoperability is required with other Registration Agencies 
(RA). XML, RDF or JSON schemas may be used. 


The DOI Kernel Schema specifies all data elements and allowed values of the metadata ex- 
change schemas (see10.1). 


4.3.4 DATA DICTIONARY 


A data dictionary specifies the data elements and allowed values of all declared DOI 
metadata. This data dictionary is defined through the DOI Kernel Schema (see 10.1). 


Terms will be added to the dictionary at the request of any Registration Agency (RA): see 
4.3.6. 


Users need not understand the underlying concepts and construction of the data dictionary 
in order to make use of it. Key features of the dictionary are: 


e The dictionary is extensible to whatever level of detail and granularity is required. 
e The dictionary is neutral as to business model. 

e The dictionary is independent of any implementation technology. 

e The dictionary allows use of any existing metadata scheme. 

e Multiple, different, specialized views can be made available. 


e Local terms can be included. 
An RA can add all their own local data elements and names into the ontology, and use 
only those terms they need. 

e The dictionary can include different terms from different internal systems and map them 
together. 

e The dictionary incorporates external and standard schemes such ISO territory, currency 
and language codes, and sector specific external schemes, allowing them to be treated 
seamlessly alongside local terms. 


e Any public terms are accessible to all RAs. 


NOTE The data dictionary was previously specified through the DOI Data Dictionary file which is 
no longer actively updated. The last update of the DOI Data Dictionary was in 2015 and can be 
found on the DOI web site*'. 


4.3.5 UNDERLYING ONTOLOGY 
As described in 1.4, the DOI data model is based on the INDECS framework. 


31 https:/ /www.doi.org/resources/DOI%20Data%20Dictionary%202015-03-23.pdf 
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The ontology logical data model, providing a consistent and logical world view, differs 
from the traditional taxonomic approach to knowledge representation in that it does not fol- 
low a rigid parent/child hierarchical structure. Terms may inherit meaning from more than 
one parent and a more complex relationship may be maintained. An interoperable data 
dictionary contains terms from different computerized systems or metadata schemes, and 
shows the relationships they have with one another in a formal way. An illustrative graphic 
of the high level concept model is provided on the DOI web site (Data Model Underlying 
Ontology**) and further documentation is available. Please consult the DOI Foundation for 


further information. 


4.3.6 DATA MODEL EXTENSION AND MAINTENANCE 


Registration Agencies can request: 


e the addition of new terms to the DOI Kernel Schema, or the publication of additional 
metadata schemas 


e the addition of new values to open lists of values of the DOI Kernel Schema 


Authority to make changes in the existing DOI schemas lies with the Schema Working 
Group. A fundamental role of the DOI Foundation is to provide assurance to users that the 
changes have been peer-reviewed, tested in practical implementations, and are based on 
sound principles. 


For more information, see 7.4. 


4.4 METADATA INTEROPERABILITY 


The first aim of DOI data model policy is to promote interoperability within the network of 
DOI name users. It does this by providing ways of achieving semantic compatibility between 
different Registration Agencies. 


4.4.1 MOTIVATIONS FOR INTEROPERABILITY 


Standardization of any kind is driven by a need for interoperability. If a Registration 
Agency (RA) is issuing DOI names for referents for use within a private domain where that 
RA is able to command all aspects of metadata gathering and output, then it has no need 
for standardization or conformance with DOI data model obligations. The RA will lay out its 
schemas and declarations, and its providers and users should conform to them. Such a situ- 
ation is described as restricted use of the DOI System, and applies typically where an or- 
ganization becomes an RA for the specific purpose of issuing DOI names for use only within 
its own private organization. 


However, such isolation is unusual. Normally, when a DOI name is issued to a referent, one 
fundamental assumption may be made about interoperability: the RA or the referent pro- 
vider may wish (now or in the future) that the DOI name should be available for use in ser- 
vices provided by other RAs. For example, where several RAs are issuing DOI names to 


32 https: / /www.doi.org/resources/ DataModelUnderlyingOntology.pdf 
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journal articles from different publishers, it is likely that some RAs and publishers will want 
their DOI names to be included in journal-related services supported by other RAs. 


In a similar way, many RAs will want DOI names issued by other RAs to be available for in- 
clusion in services they themselves are providing. Such interoperability is one of the princi- 
pal benefits of the DOI System. 


As the RA network grows, such requirements are emerging, and where specific opportuni- 
ties do not yet exist they are anticipated. In such circumstances neither the RA nor the refer- 
ent provider wishes to issue a second DOI name for the referent, nor to provide and cap- 
ture the input metadata all over again from its source. 


4.4.2 ACHIEVEMENT OF INTEROPERABILITY 


Any DOI name which is intended for interoperability — that is, which has the possibility of 

use in services outside of the direct control of the issuing RA — is subject to DOI metadata 

policy: 

e The DOI Kernel Metadata ensures that the minimum set of metadata held by different RAs 
is consistent. 


e The interchange provisions of the additional metadata exchange schemas and of the data 
dictionary ensure that an efficient and extensible means of interchange exists for trans- 
porting metadata between RAs (and in future other service providers). 


The figure below shows how interoperability is achieved when the content rendering service 
of an RA (RA1) processes DOI names managed by another RA (RAZ). In this example, the 
content rendering service of RA1 receives metadata about a DOI name managed by RA2. 
To be able to process this metadata, RA1's service uses, in addition to the DOI Kernel 
Schema, the metadata exchange schema agreed between RA1 and RA2. 


RAI with prefix 10.998 


doa 


Metadata of 
10.999/ 12345 


RA2 with prefix 10.999 
Metadata Metadata Are 
Services declarations sed on 


Figure 10 Achievement of interoperability 
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4.5 AUTOMATED INTEGRATION OF METADATA 


The DOI Foundation recognizes that the automated integration of metadata is the key to re- 
alizing the full potential of the DOI System. This is also the underlying objective of the Se- 
mantic Web and Linked Data: that the Web should be seen as a medium for structured, in- 
terlinked and machine-processable information, as much as, in its current form, a network 
of documents presenting the information for human consumption. 


The DOI Kernel Metadata and the data dictionary exist to provide a basis of good practice 
and a start point for the integration of metadata for different DOI referents. Initiatives such 
as Linked Open Data provide further essential infrastructure, but only in technology and 
syntax: they do not provide solutions at the level of shared meaning (semantic alignment) 
for the automated integration of different datasets which can allow services from different 
RAs and other parties to interact fully without human intervention or a plethora of one-to- 
one "silo" solutions. 


The key to this is the development of well-structured metadata schemas and of services 
which make use of the semantic mapping capabilities of tools such as the DOI Kernel 
Schema. The DOI Foundation will provide support to their RAs where they choose to co-op- 
erate in the development of such services. 
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Chapter 5 


DOI I 


RES VICES 


This chapter describes the identifier / resolution services included in the DOI System pack- 
age. 


In This Chapter 
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5.1 IDENTIFIER / RESOLUTION SERVICES BASED ON THE 


HANDLE SYSTEM 


The DOI System offers DOI identifier / resolution services through the Handle System which 


meets the functional requirements defined by ISO 26324. 


5.1.1 ISO 26234 FUNCTIONAL REQUIREMENTS ON THE RESOLU- 


TION SYSTEM 


According to ISO 26234, the technology deployed to manage the resolution of the DOI 


name shall support the functions listed below: 


internet compatible: transmission via the global information system that is logically linked 
by a globally unique address space and communications 


first class naming: identifiers resolved by the system shall have an identity independent of 
any other object 


unique identification: the specification by an identifier string of one and only one referent 


functional granularity: separate resolution of an object whenever it needs to be distin- 
guished 


data typing: The extensible definition of constraints placed upon the interpretation of 
certain data entries in a resolution record, such that data values with similar constraints 
can be grouped and treated in the same way. 


multiple resolution: the simultaneous return as output of several pieces of current infor- 
mation related to the object, in defined typed data structures 

Resolution requests should be capable of returning all associated values of current infor- 
mation, individual values or all values of one data type. 


designated authority: The administrator of an identifier shall be securely identified and 
capable of transfer. 


appropriate access to resolution records: Changes to a resolution record shall be rec- 
orded and shall be capable of providing access to the data on which the administrator 
depends and privacy and confidentiality from those who are not dependent on it. 


DNS independent but compatible: not reliant on the Domain Name System (DNS), but 
capable of working with DNS domain naming and resolution services 


granularity of administration: DOI names can be administered individually or in groups. 
scalability: 

o efficient and infinitely scalable protocol 

o no limitations on absolute number of identifiers assigned or length of identifier string 


unicode compliant 


NOTE The regular update of the DOI records is crucial to maintain quality services. 


5.1.2 INTRODUCTION TO THE HANDLE RECORD 


With the Handle System, a Handle is resolved to a set of elements called the Handle Record 


(the DOI record in case of a DOI name). An element is a typed data. Predefined types exist 
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in the Handle System and new types can be added at any time (the process for adding new 
types is under development). For example, a DOI name could resolve to a Java servlet, or 
other dynamic mechanism. 


An element inside a DOI record may be: 
e a link to a resource: web address, IP address, etc. 


e metadata: description, type, terms & conditions, ownership, etc. of the entity represented 
by the DOI name 


e security information: public key, digital signature, etc. 
e administration information: administrator of the DOI record with permissions 
e state information: entity status, etc. 


The following figure shows a DOI record example. 


record 


List of 
elements 
in the Permission Ss 2 
DOI U 17.04. p level VC- aex: 700050 8 
HS_ADMIN: handle=0.na/10.1038; index=200; [delete hdl,read val, mod ral,de 8 


val,add val,modify a 
Last Modified: 2021.12.02 08:10:15 CET Expiresiniday admin:rw public:r- index: 100 


Figure 11 DOI record example 


An element consists of: 
e an index: unique element identifier inside the DOI record 


e a global and registered type (for example, URL, description, IP address, email address, 
etc.) 


e a value (data) 


e a permission level: specifies if the value is publicly available or not and if it can be 
changed by an authorized administrator 


e a timestamp 
e a Time To Live (TTL): specifies how long the element value can be cached before the in- 


formation source should again be consulted 


NOTE An element inside a Handle Record can point to one or several Handles or to one or several 
elements in the same or in another Handle Record. 


5.1.3 HANDLE SYSTEM SERVICE ARCHITECTURE 


This section introduces briefly the Handle System services. For more information, see Digital 
Object Identifier Resolution Protocol (DO-IRP) Specification”? 


33 https:/ /www.dona.net/sites/default/files/2022-06/DO-IRPV3.0--2022-06-30.pdf 
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The Handle System consists of a single distributed Global Handle Registry (GHR), and un- 
limited number of Local Handle Services (LHS): 


e Identifiers (called Handles) are managed by LHSs. Handles under the same prefix are 
managed by the same LHS. 


e The GHR stores the information necessary to locate the LHS responsible for any Handle 
in the system. 


To resolve a Handle, a Handle System client will first connect to the GHR which will redirect 
it to the LHS responsible for the requested Handle. 


To understand in more details how the GHR and LHS work, it is necessary to introduce first 
the prefix Handle concept. 


INTRODUCTION TO PREFIX HANDLES (0.NA PREFIX) 


Specific Handles are used in the Handle System to represent the prefixes: 
e The Handle of a prefix is in the format "0.NA/<prefix>". 


e The record of a prefix Handle (record returned by Handle resolution) contains admin- 
istration data for managing the prefix. For example, 0.NA/ 10.100 record stores the lo- 
cation (service information) of the LHS responsible for the resolution of DOI names under 
10.100 (see also a prefix handle example in section 10.6). 


GLOBAL HANDLE REGISTRY (GHR) 


The GHR is a distributed registry whose operation is managed collaboratively by the DONA 
Foundation and multiple organizations. An organization that is authorized by the DONA 
Foundation to participate in the distributed administration of the GHR is referred to as a 
Multi-Primary Administrator (MPA). Each MPA is "credentialed" and allotted a zero-delim- 
iter prefix by the DONA Foundation. It operates its own GHR Service in accordance with 
the Foundation procedures, and coordinates it with the other MPAs and DONA on a multi- 
primary basis. 

The DOI Foundation is an MPA and was allotted the prefix 10. 

The GHR consists of: 

e the GHR services of the MPAs called MPA GHR Services 

e the GHR Service operated by the DONA Foundation 

An MPA GHR Service provides: 


e first-level resolution of Handles 
The GHR is the first access point for any client requesting a Handle resolution. Based on 
the prefix Handles hosted in the GHR, it redirects the client to the Local Handle Service 
(LHS) responsible for this Handle. 


e administration for its assigned credential prefix 
The MPA GHR Service allows the creation and maintenance by an authorized administra- 
tor of the one-delimiter prefix Handles derived from the credential prefix. All prefix Han- 
dles managed in a GHR Service are automatically copied across all the other GHR Ser- 
vices. 
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The GHR stores only the records of zero- and one-delimiter prefix Handles (up to the limit 
of one million). The other prefixes are managed through LHSs. 


eT ae MPA GHR Service 
= Credential Prefix 11 
Credential Prefix 86 


Global Handle Registry 
All zero- and one-delimiter prefix 
Handle Records are avtomatically 
and securely replicated among all 

GHR Services 
MPA GHR Service 
Credential Prefix 22 MPA GHR Service 
Credential Prefix 20 


Figure 12 Global Handle Registry (GHR) 


doi Foundation 


MPA GHR Service 
Credential Prefix 10 
MPA GHR Service 
Credential Prefix 21 


doi 0015 


..* 


LOCAL HANDLE SERVICE (LHS) 


An LHS is operated independently by a service provider and is assigned one or several 
prefixes. 


LHS INSTANCES: HANDLE AND PREFIX 


There are two types of LHS instances: 


e Handle LHS 
A Handle LHS hosts and provides resolution and administration of all Handles under a 
given prefix. 


e Prefix LHS 
A Prefix LHS hosts and provides resolution and administration of prefixes derived from a 
given prefix. 


NOTE Administration means creation, modification and deletion of the Handle Records. It requires 
administrator permissions. For more information, see Digital Object Identifier Resolution Proto- 
col (DO-IRP) Specification®’. 


34 https:/ /www.dona.net/sites/default/files/2022-06/DO-IRPV3.0--2022-06-30.pdf 
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The same LHS can provide both instances and can be responsible for any number of pre- 
fixes. 


10.500 /65_z8rt qi 0.NA/ 10.500.80 ii 
10.500 /8 4_tégf 0.NA/ 10.500.50 


Figure 13 The two types of Local Handle Service (LHS) 


doo? 


Both these LHSs operate with the same LHS software and are configured the same way. 


SERVICE SITES OF AN LHS 


Handle System service components are scalable and extensible to accommodate any large 
amount of service load. An LHS may consist of multiple service sites, each hosting a full rep- 
lica of the Handles managed by the service. A site may be a primary site (it means that it 
can be used for administrative operations: to create, modify or delete Handle Records 
stored in its database) or a mirror site (no administrative operation is possible). Each ser- 
vice site may also consist of a cluster of computers working together, each with a particular 
subset of the Handles managed by the service. Having multiple service sites avoids any sin- 
gle point of failure and allows load balancing among these service sites. Using multiple 
servers at any service site distributes the service load into multiple server processes and al- 
lows less powerful computers to be utilized for the name service. 


Primary service site Mirror service site 1 


Server 1 Server 2 Server Server 
1 2 POR 
/10:500/1-s6z' || 1000/10 a|] 


Cluster of computers (LHS servers) 


Figure 14 Service sites of an LHS 


5.2 DOI DIRECTORY 


The DOI Directory is a virtual service consisting of Handle System services (see 5.1.3) and 
web proxies located and configured to provide highly reliable resolution, administration, 
and backup for all DOI names, regardless of the varying administrative arrangements of 
the Registration Agencies (RA). This approach provides the flexibility RAs need to develop 
individual business models and meet customer requirements while guaranteeing reliable 
overall service. 
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The DOI names are stored in Local Handle Services (LHS) which are usually managed by 
the DOI technical support service provider but may also be operated by the RA. 


NOTE All DOI names must be registered in the DOI Directory. 


5.2.1 LOCAL HANDLE SERVICES (LHS) USED IN THE DOI SYSTEM 


The DOI Foundation has contractual agreements for provision and persistence of the Han- 
dle System with the DOI technical support service provider who: 


e provides technical and operational support for the DOI System 


e usually manages the Local Handle Services used in the DOI System (DOI LHS). A Regis- 
tration Agency (RA) can choose to install and use the Handle LHS responsible for their 
DOI names (A Prefix LHS will always be managed by the technical support service pro- 
vider.). 


5.2.2 DOI LHS OPERATED BY A REGISTRATION AGENCY 


A Registration Agency (RA) can run the Local Handle Service(s) responsible for the DOI 
names of their registrants. This may the best choice for an RA who: 


e wish to have immediate control of business-critical infrastructure components such as DOI 
registration 


e plan to implement high performance standards for administration and resolution by 
choosing levels of performance appropriate to their application 


In this case, the DOI technical support service provider will run a mirror service of this LHS 
so that they have a copy of the DOI name database managed by the RA. The DOI Founda- 
tion requires that RAs be responsible for modification of the configuration of their Handle 
servers to allow a secondary server installation at the DOI technical support service pro- 
vider. In the illustration below, if the RA who was allocated the prefix 10.550 wants to run 
their own LHS, then the technical support service provider would run one of the mirror LHSs. 


doi 0014 


Housed and 
operated by CNRI 


Figure 15 Handle LHS operated by a Registration Agency 
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NOTE Choosing the option of running their own LHS will require more technical expertise on the 
part of the RA. If an RA is interested in running a DOI LHS it is wise to schedule a technical over- 
view meeting with the staff of the DOI technical support service provider. To set this up or to an- 
swer any questions please send email to the DOI technical support service provider at doi-ad- 
min@doi.org. 


5.3 DOI RESOLVERS 


To be able to use the core resolution service of the DOI System, a DOI resolver is required. 
A DOI resolver is a client of the Handle System. 


5.3.1 DOI PROXY 


With the HTTPS Proxy Server of the DOI System (https:/ /doi.org), users can resolve DOI 
names from any standard web browser by using the URL syntax. For example, the resolu- 
tion of the DOI name "10.10.123/456" would be done from the address 

https:/ /doi.org/ 10.123/456. 


NOTE An earlier proxy address (https:/ /dx.doi.org) is maintained but its use is discouraged. 


DOI PROXY SERVICE CHARACTERISTICS 
The DOI Proxy is accessible over IPv6, and supports DNSSEC. 


The DOI Proxy consists of multiple servers running at multiple locations, with the load dis- 
tributed evenly across all servers. 


NOTE The core DOI name resolution service is used by the DOI Proxy but is not constrained by the 
DOI Proxy. 


DOI PROXY RESOLUTION FUNCTION 


The DOI Proxy supports the single and multiple DOI resolutions: see 5.4. 

The resolution process is as follows: 

1. The DOI Proxy receives an HTTPS or HTTP request from a requester for resolving a DOI 
name. The request is in the format hitps:/ / doi.org/<doi-name>?<parameters>. For more 
information, see 10.3. 

2. The DOI Proxy requests the DOI name resolution from the GHR (or retrieves it from its 
cache, if the record is in its cache and no authoritative query is done) which redirects it 
to the responsible DOI LHS. Before sending the resolution request, the DOI Proxy de- 
codes the percent-encoded DOI name if necessary (see 10.2.2). 

3. The responsible DOI LHS returns the DOI record to the DOI Proxy. 

4. The actions performed by the DOI Proxy depend on the query parameters. Typically: 

o If the DOI record contains a 10320/LOC element then the DOI Proxy interprets the 
XML code it contains and embeds the resulting URL in an HTTP(S) redirect, and sends 
it back to the requester (see 5.4.2). 


o Otherwise, the DOI Proxy redirects the requester to the first URL element it finds in the 
DOI record (see 5.4.1). 


DOI Handbook 


65 


NOTE To speed resolution, the proxy servers cache DOI record values, with the TTL (Time To Live) 
set to one hour. This means that if a DOI record value is changed, it can take up to one hour before 
the new value is returned. This setting is specific to the current proxy system and different DOI soft- 
ware clients could be configured to behave differently. The default Handle Record TTL setting is 24 
hours, which is a common TTL for Internet applications. While the one hour setting currently holds 
for the DOI proxy, it would be best to design various DOI workflows assuming the more conserva- 
tive 24 hour period. 


DOI PROXY MAINTENANCE COMMITMENT 


The DOI technical support service provider and the DOI Foundation are committed to main- 
taining the DOI Proxy in perpetuity, as it is an essential component to maintaining the integ- 
rity of the millions of instances of DOI name-based web links. Maintaining the utility of 
those links over time will require maintaining both the core DOI System and the specific 
gateway service, doi.org, that those links reference and so use to gain access to the core 
DOI System. This, of course, is not at all unique and is just another variation on the Internet 
theme of layering services on top of one another. doi.org is itself dependent on the Domain 
Name System (DNS), which is itself dependent on IP addressing and routing, etc. 


5.3.2 CUSTOM DOI RESOLVERS 


Additional DOI resolvers can be built and additional methods can be used to access the 
core DOI name resolution system without interfering in any way with the ongoing operation 
of the DOI Proxy. For more information, see 7.5. 


5.3.3 DOI REST API 


The DOI REST API allows programmatic access to DOI name resolution services using 
HTTP(S). A REST API request can be made by performing a standard HTTP GET. The API re- 
turns JSON. 


The DOI REST API provides specifications for using the Handle System but avoids the need 
for users to address the Handle System directly and in depth. The API ensures the portability 
of any code written to address DOI System services and applications. 


For technical details, see 10.4. 


NOTE In addition to Java, API libraries are available for Python, Perl, and C. 


5.4 DOI RESOLUTION FUNCTIONS 


This section describes the resolution functions provided through the DOI System. They are 
supported by the DOI Proxy and the DOI REST API. 


5.4.1 SINGLE DOI RESOLUTION 


The single resolution function of the DOI System consists in returning to the requester the lo- 
cation stored as an URL element in the DOI record. With the DOI Proxy, the requester is re- 
directed to this URL through an HTTPS request (see 1.5.1). The process is as follows: 


1. A user sends a DOI name resolution request to a DOI resolver. 
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2. The DOI resolver sends a resolution request of the DOI name to the GHR. The GHR redi- 
rects the resolver to the responsible DOI LHS which returns the DOI record to the re- 
solver. 


3. The DOI resolver retrieves the first URL element it finds in the list of DOI record elements 
and returns this URL to the requester. 


5.4.2 MULTIPLE DOI RESOLUTION 


With the multiple DOI resolution, multiple resources in potentially any format can be man- 
aged in the DOI record. The multiple resolution is typically used to manage several URLs of 
the same referent (see 1.6.1) or to select a different URL according to various criteria. 


To manage multiple resources in the DOI record, an element of the predefined type 

10320/LOC is used. This element allows specifying complex rules formatted in RDF/XML 
which can be interpreted by the DOI resolver to retrieve the resources to be returned to the 
resolution requester. For example, a resource may be selected according to the context of 
the request (in particular, to the country of the requester). For more information, see 10.5. 


The following figure shows a DOI record containing a 10320/LOC element used to retrieve 
URL(s). The 10320/LOC element could also be stored at prefix level, thus applying to all 
DOI names under that prefix. 


Default URL [is returned by Complex rules interpre 
DO! resolvers which do not by the DOI resolver to 


support 10320/LOC) retrieve the URL(s) 


doi 0022 


Figure 16 Multiple DOI resolution (multiple URLs) 
The multiple DOI resolution process is as follows: 


1. A requester (user or application process) sends an HTTP request to the DOI resolver. 

2. The DOI resolver sends a resolution request of the DOI name to the GHR. The GHR redi- 
rects the resolver to the responsible DOI LHS which returns the DOI record to the re- 
solver. 

3. The DOI resolver recognizes the 10320/LOC element. Depending on the HTTP request 
features, the DOI resolver may interpret the code it contains and return the interpretation 
result (for example, an URL) to the requester; or it may return the raw XML code, or a list 
of possible resources (for example, a list of URLs). 

If there are DOI resolvers (other than the DOI Proxy) that do not understand the 

10320/LOC type, these resolvers would ignore it and simply apply a single DOI resolution 

request. 
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5.4.3 PARAMETER PASSING 


With the parameter passing feature, information about the context of the request (for exam- 
ple, the particular user making the request) can be included in the DOI resolution request 
sent to the DOI Proxy. Different context expressed in the request may result in different res- 
olution results. Changes in context are predictable, and do not require the original creator 
of the hyperlink to handcraft different URLs for different contexts. 


Two URLs are involved in the parameter passing feature: 


e the referrer URL: URL sent by the requester (referrer) to the DOI Proxy and containing 
the DOI name to be resolved and the context information 


e the referent URL: URL registered in the respective DOI record (by the referent) and which 
may also contain parameters 


The DOI Proxy combines the referrer URL with the referent URL to create the out-bound link. 
It supports two different methods : 


e urlappend: simple method (see below) 


e OpenURL: deprecated method (see Appendix) 
PARAMETER PASSING WITH URLAPPEND 


With urlappend, key-value pairs can be passed to the out-bound link by placing them in the 
referrer URL as follows: 


https://doi.org/<doi-name>?urlappend=%3F<key1l>=<valuel>%26<key2>=<value2>... 
The question mark (%3F) or the ampersand (%26) must be used before each key-value 
pair. 

For example, 

the referrer URL https:/ /doi.org/ 10.1256/0035902urlap- 
pend=%3Fparam1=12345%26param2=67 89 

is combined with the referent URL https: / / www.publisher.org/resource9876 

to create the out-bound link https:/ / www.publisher.org/ re- 

source9876?%param 1=12345%26param2=6789 


If the referent URL already contains parameters then they may conflict with the urlappend 
values. In the above example, the urlappend should start with an ampersand character ra- 
ther than a question mark character. 


5.4.4 CONTENT NEGOTIATION 


Content negotiation refers to mechanisms defined as a part of HTTP(S) that make it possible 
to serve different representations of a resource at the same URL, so that the content render- 
ing software can specify which version fits their capabilities the best. In the context of the 
DOI System, content negotiation allows making a request that favors content types specific 
to a particular Registration Agency (RA) but which will also degrade to respond with a 
more standard content type for other RAs. 


A content negotiated request to a DOI resolver is much like a standard HTTP(S) request, ex- 
cept server-driven negotiation will take place based on the list of acceptable content types 
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a client provides. The request is done by using an HTTPS header "Accept" where the GET in- 
cludes several content types that are acceptable to the requesting client process (those that 
it knows how to parse), each content type with a specific preference level (quality factor). 


For example, Crossref RA uses content negotiation to redirect all requests which are not for 
the content type "text/html" to the metadata service managing the requested DOI name. To 
do so, the 10320/LOC element (which corresponds to the content type "applica- 
tion/rdf+xml") is used in the DOI record to specify the redirection to the respective 
metadata service. If the DOI resolver does not support this content type then it will redirect 
to the URL defined in the URL element (content type "text/html"). This is illustrated in the 
DOI name example below. 


Values for: 10.1525/bi0.2009.59.5.9 
Index Type Timestamp Data 


1 URL Fri Apr 1 2022 https:/ / www.sciencemag.org/cgi/doi/ 10.1126/sci- 
13:32:18 EST ence. 169.3946.635 


1000 10320/LOC Mon Jun 272021 = <locations chooseby="locatt, country, weighted"> 
14:28:25 EDT <location weight="0" http_role="conneg" href_tem- 
plate="https:/ /data.crossref.org/ 10.1126/sci- 
ence.169.3946.635" /> 
</locations> 


Figure 17 DOI record example with RDF XML content type 


Shown below is an Accept header for the content negotiated request, listing both "applica- 
tion/ citeproctjson" and "application/rdf+xml", and the metadata returned by the 
metadata service. The requesting client wishes to receive citeproc JSON if it is available, 
but can also handle RDF XML if citeproc JSON is unavailable. A preference level ("q" fac- 
tor) is used in the request to specify the preferred choice. 


$ curl -LH "Accept: application/rdf+xml;q=0.5, application/vnd.citationstyles.csl+json;q=1.0" http://dx.doi.org/10. 
1126/science.169.3946.635 


{ 
"volume" : "169", 
"issue" : "3946", 
"DOI" : "10.1126/science. 169.3946.635", 
"URL" : “http://dx.doi.org/10.1126/science.169.3946.635", 


"title" : "The Structure of Ordinary Water: New data and interpretations are 
yielding new insights into this fascinating substance", 

“container-title" : "Science", 

"publisher" : "American Association for the Advancement of Science AAAS (Science)", 

"issued" : { "date-parts" : [ [ 1970,8,14 ] ] }, 

“author" : [ { "family" : "Frank", "given" : "H: S."} ], 

"editor" : [], 

"page" : "635-641", 

"type" : “article-journal" 


} 


Figure 18 Content negotiated request with response 


5.4.5 HANDLING OF RESOLUTION ERRORS IN THE DOI SYSTEM 


Actions which result in an attempted resolution not being successful result in error messages. 
These can be provided by Registration Agencies, or by the DOI System centrally. 
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The error page provided by the DOI System directs the user to DOI help address (doi- 
help@doi.org) which is managed by the DOI technical support service provider: 


e If the problem is with the Handle System, the DOI technical support service provider re- 
sponds to the sender appropriately. 


e Ifthe DOI name is not found, a special handling is performed (see below). 


"DOI NOT FOUND" AND "DOI PREFIX NOT FOUND" ERRORS 


The entered DOI name or DOI prefix may not be found, for example, when resolution re- 
quests for DOI names are incorrectly formatted or the DOI names do not exist. In that case, 
a response page is displayed with: 
e details about the error 
To further assist users, the error response system checks to see if a user has attempted to 
resolve a DOI prefix only, or a DOI that contains multiple slashes or a trailing slash 
which might be causing the error, and advises the user accordingly. 


e the possibility for the user to send a report to the responsible RA 
If required by an RA, the technical support service provider can configure the DOI Proxy 
to automatically report the error message to the responsible RA. 


5.5 SHORTDOI SERVICE 
The shortDOI service is a public service (https://shortdoi.org/), open to anyone, that cre- 


ates shortcuts to DOI names which are often very long strings. The shortDOI service pro- 
vides a function similar to that which URL shortening services do for URLs. The service cre- 
ates short DOI names of the form 10/abcde and enables short HTTPS URIs of the form 
https: / / doi.org/ abcde that are ideal for use in email, blogs, mobile messaging and more. 
(Note that shortDOls are not themselves DOI names and therefore do not conform to the 
ISO standard syntax and other requirements. A shortDOI can only be created for an exist- 
ing DOI name.) 

The shortDOI service proxy server only resolves the shortcuts, identically to the way the 
DOI Proxy only resolves full DOI names. The service will either create a new shortcut, or re- 
turn the existing shortcut if one has already been created. 


For automated purposes, the shortDOI service can also be used by simply appending the 
original DOI name to the URL for the service. A format parameter can be used to specify 
how information is to be returned. For further information, see the shortDOI service web 
page”. 


5.6 WHICH RA? SERVICE 


Which RA? is a simple service that has been built to examine the type/value pairs returned 
from Handle resolution and provide specific information that is available from the DOI 


3 https://shortdoi.org 
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Proxy. This service returns the name of the DOI Registration Agency (RA) responsible for a 

specific DOI name, or group of DOI names. 

The service is requested by using the command 

https://doi.org/doiRA/<doi-names> 

where: 

e <doi-names>: single DOI name or a list of DOI names separated by commas 
If a DOI name contains commas, then the commas must be percent encoded (see 10.2.2). 
Note that shortDOI names are not supported. 


A bit of JSON specifying the name of the RA is returned. 


For example, resolving https:/ /doi.org/doiRA/ 10.5240/B1FA-OEEC-C316-3316- 
3A73-L will return: 


{ 
"DOI": "10.5240/B1FA-0EEC-C316-3316-3A73-L", 
"RA" : "EIDR" 

} 


] 
A full list of RA names and abbreviations can be found on the web site?ć. Possible error 
states include “Invalid DOI”, “DOI does not exist” and “Unknown”. 


36 https: / /www.doi.org/registration_agencies.html 
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Chapter 6 


DOI 


This chapter discusses some of the ways in which resolution can be harnessed to provide 
applications with the ability to resolve a DOI name to the most appropriate content chosen 
from multiple DOI resolution options. These options can include pop-up menus offering 
manual selection, and consistent automated selection through content negotiation and 
Linked Data. 


In This Chapter 
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6.1 INTRODUCTION TO DOI APPLICATIONS 


In order to maintain a persistent identifier, an active management service in collaboration 
with registrants is required. To justify that management service, a DOI application normally 
provides more value than simply registering a DOI — typically a Registration Agency offers 
an added value service, such as citation linking or metadata management. 


DOI names can identify many types of content, and may resolve to more than just a perma- 
nent, indirect link to that content. They can also provide or point to any useful information 
about the object when that information has been provided by the registrant or a third party. 
This information can include any type of descriptive metadata and any type of service re- 
lated to the object, such as rights clearance, alerting services, data visualization or any 
other associated information or service. The information can be used in many ways by DOI 
applications customized to meet users' needs. 


NOTE No ability to search from metadata to DOI name (reverse look-up) is provided by the DOI 
System. It may be offered by Registration Agencies or other services as a value-added feature. A 

variety of technologies are in use for this purpose among the RAs, including the Cordra37 registry 
system as well as custom applications. 


6.2 USE AND EXTENSION OF THE RESOLUTION FUNCTIONS 


At the most basic level, all DOI applications query the DOI System by resolving a DOI 
name. The request can be structured to ask for all of the DOI record elements associated 
with that DOI name, or all of the elements of a specific type and/or index, etc. (see DOI 
Proxy Query Command Format). Applications are built to understand one or more of the el- 


ement types, and parse, evaluate, and take action based on the corresponding element val- 
ves. 


The DOI record that is associated with a DOI name is stored in the DOI System in 
type/value pairs (see 5.1.2). This is extremely flexible and open: new types can be added 
at any time, and the values can be of arbitrary complexity. Type/value pairs can be admin- 
istrative (creation date, permissions, etc.), well known and standardized (URL, email, 
10320/LOC, etc.), or created by a Registration Agency for a specific application purpose 
(for example, a custom type with a value that is binary data or a specially formatted 

string). There can be many type/value pairs associated with a DOI name, and multiples of 
the same type. 


Associating XML, or other machine readable data with a DOI name, expands the utility of 
multiple resolution even further, adding features, and offering more options for negotiating 
content, and facilitating the creation of Linked Data applications. 


NOTE Newtypes should, but are not required to, be registered in the Handle System as Handles. 
As a general rule types containing a slash (for example, 10320/LOC) should be considered full 
Handles and those without a slash (for example, URL) should be assumed to be suffixes under the 
O.TYPE prefix (with the previous example: 0.TYPE/ URL). The type Handle Record may define the 


37 https:/ /www.cordra.org/ 
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syntax, structure, possible semantics, or any other necessary descriptive characteristics of the cor- 
responding value field. For more information, see the Digital Object Identifier Resolution Proto- 


col (DO-IRP) Specification®®. 


6.3 APPLICATIONS OF THE 10320/LOC ELEMENT 


The 10320/LOC element can be used if multiple resolution is required. 


6.3.1 CHOOSE-BY MECHANISM 


Multiple resolution with 10320/LOC element (see 5.4.2) is useful for building applications 
where the required evaluation is to choose from a set of possible outcomes based on some 
criteria. An application developer could create a type in which to store values used by a cli- 
ent to generate a menu of options for a user when the user resolves a DOI name. In the case 
of a document, the user might be given the option to view the document, view document 
metadata, share the document by emailing the URL to an associate, visit the author's blog, 
etc. For a dataset, the choices offered to the user on the landing page may include viewing 
the complete dataset, viewing only selected data, or some other choice of interaction with 
the dataset based on the information made available to a client via resolution of the DOI 
name. 

For example, scholarly journal articles are assigned one DOI name, but they can be availa- 
ble from multiple web sites, and readers may wish to download an article from a service to 
which they are subscribed. Crossref uses multiple resolution to enable users to resolve an 
article's DOI name, and choose which version of an article they wish to view, as illustrated 
below. 


UNIVERSITY OF CALIFORNIA PRESS 
JOURNALS + DIGITAL PUA serine 


You are trying to access: 


BioScience (2009),59(5):418 


This articie is available from multiple websites, Please select one of the following websites to access the article or view other options. 


m 
™ BioOONne 2" Bicone 


Figure 19 Choose-by mechanism example 


38 https:/ /www.dona.net/sites/default/files/2022-06/DO-IRPV3.0--2022-06-30.pdf 
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6.3.2 AUTOMATED SELECTION OF AN URL ACCORDING TO VARI- 
OUS CRITERIA 


Multiple resolution with 10320/LOC element (see 5.4.2) can be used to enable a DOI re- 
solver to choose what the outcome of resolving a DOI name will be for a specific user, 
based on a given criteria. The figure below shows (non-administrative) elements associated 
with DOI name 10.1525/bi0.2009.59.5.9. When this DOI name was registered it had a 
single URL element (type of URL and value, aka data, equal to a JSTOR URL). A 
10320/LOC type was added to provide instructions for offering other resolution options 
(see 10.5.1 for information about the XML attributes used in 10320/LOC element). When 
this record is returned to the DOI Proxy, it recognizes the 10320/LOC type and, if asked 
to do so, performs an evaluation of the location values based on a given criteria. 


Values for: 10.1525/bio0.2009.59.5.9 
Index Type Timestamp Data 
1 URL Sun Jan 02 2022  https:/ /www.jstor.org/ stable/ 25502450 
13:32:18 EST 
1000 10320/LOC Mon Jul 27 2020 <locations chooseby="locatt, country, weighted"> 
13:18:25 EDT <location id="1" cr_type="MR-LIST" href="https:/ / mr.cross- 


ref.org/ iPage?doi=10.1525%2Fbio.2009.59.5.9" 
weighi="1" /> 

<location id="2" cr_src="unca" label="SECOND- 
ARY_BIOONE" cr_type="MR-LIST" 
href="https:/ / www. bioone.org/doi/full/ 10.1525/bio.20 
09.59.5.9" country="gb" weight="0" /> 

</locations> 


Figure 20 10320/LOC example 


The DOI Proxy may be required to (see also 10.3): 


e ignore type 10320/LOC 
In that case, the DOI Proxy would resolve 10.1525/bi0.2009.59.5.9 and select the URL 
value https:/ /www.jstor.org/ stable/ 25502450. This action would be performed by 
any DOI resolver not knowing the type 10320/LOC. 

e resolve 10.1525/bi0.2009.59.5.9 and return to the user both of the URLs in the cr_type 
attributes in the 10320/LOC value, letting the user choose the next action (choose -by 
mechanism) 

e resolve 10.1525/bi0.2009.59.5.92locatt=country:gb 
In that case, the DOI Proxy would determine the user's geographic location from their IP 
address. It would then select the URL 
https: / /www.bioone.org/doi/full/ 10.1525/bi0.2009.59.5.9 for users in the UK 
("gb" code), and would perform a random selection for all others. 

e resolve 10.1525/bi0.2009.59.5.92locatt=id: 1 
In that case, the Crossref metadata service at https: / /mr.cross- 
ref.org/iPage?doi=10.1525%2Fbi0.2009.59.5.9 would be selected. 
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6.4 REDIRECTION TO LINKED DATA SERVICES 


Linked Data is the general term for a set of best practices for exposing data in machine - 
readable form using the content-negotiation feature of the standard HTTP(S) web protocol. 
These best practices support the development of tools to link and make use of data from 
multiple web sources without the need to deal with many different proprietary and incom- 
patible application programming interfaces (APIs), and use of HTTP(S) to request data in 
structured form meant for machines instead of human-readable displays. 


In Linked Data applications, evaluation of the HTTP(S) request that comes in to the proxy 
service determines if it is a request for content of form application/rdf+xml, or one of a few 
similar types that are commonly understood to be a request for Linked Data. These requests 
for special content types would come from automated processes or special "linked data" 
browsers and would not normally come from end users. The utility of this, of course, is that 
it allows outside developers to query the extensive and reliable set of metadata records 
held by Registration Agencies (RA) to build value-added services. 


Some RAs are using this approach for all of their DOI names, offering services that return 
metadata in a common machine-readable format. A significant advantage of applying 
Linked Data principles and technologies to DOl-registered material is that it is "data worth 
linking to": it is curated, value-added, data, which is managed, corrected, updated and 
consistently maintained by RAs. It is also persistent, so avoiding "bit-rot". In practice, the 
quality of Linked data implementations is only as good as the data you are linking to, and 
the meaning and contextualization of the link you use. The DOI System can offer "curated 
data", it means consistent, managed, linking so you can link to other "quality data" with 
confidence, while still using the standard Linked Data technologies. 


The following figure shows a redirection to the metadata service managing the DOI name. 
The 10320/LOC element information can be stored at prefix level (see 10.5.3): should an 
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RA at some point need to change their approach to linked data and point to a different ser- 
vice or use different parameters, the change could be made to a single DOI prefix and it 
would apply to all of the millions of DOI names automatically. 


(2) © 


Resolution request 


for 10.3390/s18020479 
The DOI Proxy interprets the XML 
Q code in the DOI record returned 
HTTPS request for the Handle System and retrieves the 
RDF+XML content address of the metadata service 


responsible for the DOI name. It 
redirects the request to this service. 


A user asks for Redirection 
the resolution of 


10.3390/s 18020479 © 


Request result 
(metadata) 


RA’s Metadata Metadata declarations 


Service for assigned to 
10.3390/s18020479 10.3390/s18020479 


Figure 21 Dynamic building of a web page enriched with metadata 


For more information, see 5.4.4. 


6.5 DYNAMIC IDENTIFICATION OF THE FRAGMENTS OF AN 
ENTITY 


In some cases, applications may require the identification of fragments of an entity, rather 
than the full entity. Each such fragment may be assigned a separate DOI name if it is practi- 
cal and useful to do so (for example, if a specific table within a book is likely to be re-used 
many times). However, this may not always be possible: there are also cases where one 
wishes to identify in principle any fragment of this entity as it becomes needed on the fly. 
For such cases, use may be made of Template Handles (see section 11 in the Handle.net 
Technical Manual®’): a single template DOI Handle can be included in the form of a base 
formula that allows any number of extensions to that base to be resolved as full DOI Han- 
dles, according to a pattern, without each such Handle being individually registered. This 
would allow, for example, the use of DOI names to reference an unlimited number of 
ranges within a video without each potential range having to be registered with a separate 
Handle. If the pattern needs to be changed, for example, the video moves or a different 
kind of server is used to deliver the video clips, only the single base DOI name (Handle) 


3° http:/ 7/www.handle.net/tech_manual/HN_Tech_Manual_9.pdf 
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needs to be changed to allow an unlimited number of previously constructed extensions to 
continue to resolve properly. 
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Chapter 7 


DESI 
DEVE 
DOI 


This chapter assists business analysts and developers in designing and developing applica- 
tions based on the DOI System. 


Before starting the design or development of a DOI application, you should have read the 
previous chapters of the Handbook. 


See also 10.7. 


In This Chapter 
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7.1 


CHECKLIST FOR DESIGNING A DOI APPLICATION 


The DOI System has the flexibility to meet identification and resolution requirements of any 


application domain. However, these don't come "in a box": someone needs to build the 


specific social and technical structures to support the particular requirements of a commu- 


nity, and provide applications which offer value to that community. In designing a DOI Sys- 


tem application several questions need to be considered. 


Table 3 Checklist for designing a DOI application 


The rules about what is identified, and whether two things being identi- 
fied are "the same thing", are made at the level of a specific applica- 
tion of the DOI System, and this is a role of Registration Agencies (RA). 
This deceptively easy question (usually known as "granularity") is one 
of the most difficult encountered in all discussions about identifiers (but 
the one most commonly overlooked) and an answer is often much more 
difficult than it might at first appear. The answer to when two things are 
"the same thing" is entirely contextual, it means what a specific applica- 
tion will need to distinguish. 


What are we 
identifying with 
this identifier? 


What are we re- 
solving to from 
this identifier? 
What metadata 
are we associat- 
ing with this DOI 


name? 


What are the in- 
teroperability re- 
quirements? 


How will the DOI 
application be 
paid for? 


Chapter 5 


Chapter 4 


A DOI name can resolve to anything. At minimum, it will resolve to a 
URL, but there may be multiple URLs or it can be configured to return 
multiple other data types. 

Without an explicit structured metadata layer, an identifier essentially 
can have no meaning at all outside a specific application. Most DOI 
names are not yet used for widespread interoperability, but are used 
within specific applications. They do not need to reveal explicit struc- 
tured metadata, but RAs maintain Kernel metadata and additional ap- 
plication metadata which may be delivered in a number of ways. 


The DOI System has a mechanism for interoperability with other stand- | 4.4 
ards. If the application is in a sector where other identifiers or metadata 
schemes are already in use, an RA will need to work out an implemen- 

tation of this in detail that is practical for the community that they serve. 


A cost is associated with managing persistence and with assigning iden- | 2.2.2 
tifiers and data to ensure long-term stability, because of the need for 

human intervention and support of an infrastructure. In the DOI System 

the way in which these costs are recouped depends on the application. 

RAs are free to establish their own business model for the allocation of 

DOI names. The services offered by a DOI RA will include more than 

simple provision of a DOI name: these value added services may in- 

clude data, content or rights management. There is no single business 

model applicable to all DOI RAs (and consequently no single answer to 


the question of how a DOI name is paid for and what it costs). 


7.2 DESIGN CONSIDERATIONS 


Flexibility and scalability are important features of well-designed DOl-enabled services. 
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The most flexible and scalable approach is to use the DOI System as a lightweight redirec- 
tion mechanism, resolving identifiers to well-structured data. This approach can be used to 
provide DOl-related services beyond that of a single level of redirection. In addition to 
simply resolving a DOI name and getting back a single URL, DOI registration agencies may 
offer multiple resolution services, linking a DOI name to multiple options about the content 
(for example, bibliographic metadata), and those options may include requests for particu- 
lar representations of metadata, or metadata useable only for particular contexts. 


Developers may choose to put all or most of the information provided by the service in the 
DOI System itself, such that the DOI system is the primary service provider, or alternatively, 
use the DOI System to point to one or more external services to provide the desired infor- 
mation and functions. For example, the DOI System may be used to store all of the data re- 
quired to display a simple menu of labelled options for a user to pick from, but redirecting 
to an external service that stores large quantities of scientific data for visualization tools, or 
multiple image files, might be preferable to storing that data in the DOI System. 

Developing applications that store, use, and share high-quality machine-readable data ina 
standardized format is a further design consideration. DOI applications can be designed to 
conform to the best practices of Linked Data, a well-known concept of exposing data in ma- 
chine-readable form, using the content negotiation feature of the standard HTTP web proto- 
col. 


NOTE The use of HTTPS over HTTP is highly recommended. 


Creating services that take advantage of DOI structured data to create consistency across 
RA applications is encouraged. Collaboration is encouraged whenever possible. Third party 
application developers not part of the DOI Foundation are also encouraged to be part of 
the process of creating services that take advantage of DOI structured data. 


A sampling of DOI application services based on multiple resolution and content negotia- 
tion are described in Chapter 6. New services may be created at any time. Questions can 
be sent to info@doi.org. 


7.3 DEFINING AN IDENTIFIER SCHEME 


If you need to define a new identifier scheme, consider the following: 
e Avoid re-inventing the wheel: if it appears that you need to devise a new identifier 
scheme, examine whether the problem can be avoided by re-using existing identifiers. 


e If anew scheme is needed, consider if an existing protocol or identifier registry can be 
harnessed to implement your scheme. 


e Register your scheme with an appropriate public namespace declaration. 


e Provide easy links for semantic mapping by specifying a well-formed metadata scheme 
and publishing it. 


e Consider the community and business implications for others who may need to use your 
scheme. 


e Provide clear guidance on rights and obligations of use of your scheme. 
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e Adopt identifiers with a mechanism for ensuring persistence. 


7.3.1 INTEGRATING ANOTHER IDENTIFIER SCHEME 


Where syntax rules permit the incorporation of an existing identifier from another scheme 
as part of the DOI name, such rules shall not form part of ISO 26324. In such cases, atten- 
tion is drawn to the following points. 


e The same referent shall be denoted by both the DOI name and the included identifier 
string, to the degree that is necessary to distinguish it as a separate entity within each 
identifier scheme. 


e Within the DOI System itself, the DOI name is an opaque string. No definitive infor- 
mation relating to the other identifier scheme should be inferred from the specific charac- 
ter string used for a DOI name, and the DOI name is not guaranteed to be usable in any 
non-DOI applications designed for the other identifier scheme. 


e Specific syntax rules for the incorporation of an existing identifier from another scheme 
shall be maintained by the ISO 26324 Registration Authority. 


7.4 MANAGING DOI METADATA SCHEMAS 


Schemas are used to specify Kernel and additional metadata (see 4.3). You may want to 
update existing schemas or create new ones. 


7.4.1 CREATING OR UPDATING A METADATA SCHEMA 


Authority to make changes in the existing DOI schemas lies with the Schema Working 
Group. Any member of the DOI Community may make proposals for updates to a schema, 
or for introducing a new schema, at any time. Implementing the changes will be the respon- 
sibility of the DOI Foundation's selected technical provider as managers of the schemas, 
who will acknowledge each proposal and give an estimated deliverable time according to 
the scope and complexity of the proposed changes. 
The procedure is: 
1. initial proposal 
DOI RA member submits suggestions for changes to a schema, or for a new schema, to 
the Schema Working Group. These may be in the form of specific proposals (for exam- 
ple, the addition of a new allowed value or element) or of requirements (for example, a 
request to introduce a way of identifying the owner of a proprietary ID scheme in the 
Kernel). Others on the list may comment. 


2. proposal agreed 
If necessary, request for clarifications or comments and suggestions for implementation 
will be made, allowing time for anyone else on the list to respond. The aim is to reach 
consensus before going ahead to implement the change, and so the time period to reach 
agreement will vary according to the proposal: some will be very quick, other proposals 
may be abandoned if there is no agreement. 
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3. draft implementation 
Once the proposal or requirement is clear, an estimated time will be provided for the up- 
date, and then issuance of new drafts of the appropriate schema(s) in the time frame, let- 
ting the Schema Working Group know in advance if there is going to be delay for any 
reason. 

4. review updated or new draft schema 
The group will be given an opportunity (typically a working week for routine changes) to 
make any comments on the drafts. If further revision is then needed, steps 3 and 4 will be 
repeated. 


5. release of updated or new schema 
When the updated schema is agreed, it will be put on the web site accessible to DOI 
Foundation members. 


NOTE RAs wishing to develop de novo schemes and new metadata applications are also encour- 
aged to contact the DOI Foundation for advice. 


7.4.2 ADDING TERMS TO THE DOI KERNEL SCHEMA 


Terms will be added to the DOI Kernel Schema at the request of any Registration Agency 
(RA) by the modification of the Metadata Kernel and/or its Allowed Values, or the publica- 
tion of other DOI message schemas in addition to the Metadata Kernel. Any RA may add 
new values to the open Allowed Value Sets (AVS) by registering them with the DOI Founda- 
tion. To do so, the procedure is as described in 7.4.1. 


7.5 DEVELOPING A DOI RESOLVER 


For your DOI application, you may use the DOI Proxy (see 5.3.1). Additional DOI resolv- 
ers can be built and additional methods can be used to access the core DOI name resolution 
system without interfering in any way with the ongoing operation of the DOI Proxy. For ex- 
ample, you may: 

e setup your own web-to-DOl-name proxy server 

e use the DO-IRP protocol to query the DOI System directly: see 7.5.1 


e use the DOI REST API to access to DOI name resolution services using HTTPS: see 5.3.3 


NOTE The resolution functionality might also be delivered to a browser by means of a scripting 
feature, such as JavaScript. However, this method is not recommended since languages are likely 
to evolve faster than protocols. 


As resolution is freely available, you can develop your DOI resolver entirely independently 
of the DOI Foundation, but we encourage developers to let us know about their applica- 
tions in order that we may: let others know about it if it is public; work with developers to 
improve their understanding of the DOI System and thus the success of their efforts. 
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7.5.1 DEVELOPING HANDLE SYSTEM CLIENT SOFTWARE 


An organization or individual developing Handle System client components is encouraged 
to use the CNRI client software and the standard interfaces supplied with it: the Han- 
dle.Net® Software Client Library Java™ Version“ is freely available and can be used to de- 
velop new resolution clients as needed, either for individual applications or for use in com- 


pletely separate systems. In particular, the Handle System client shall not interfere with the 
normal operation of a Local Handle Service (LHS) or other client applications in interacting 
with the Handle System client software or the GHR (see 5.1). In the event an organization 
or individual wishes to use its own interface software, it is their responsibility to ensure that 
these interfaces remain compatible with the current Handle System interface specification. 


NOTE The net.handle.apps.simple package has a number of examples of how to use the Han- 
dle client library. Contact the Handle.Net Registry Administrator at hdladmin@cnri.reston.va.us for 
information. 


7.6 CONFIGURING THE RESOLUTION ERROR MESSAGE HAN- 
DLING 


Actions which result in an attempted resolution not being successful result in error messages. 


These can be provided by Registration Agencies (RA), or by the DOI System centrally. RAs 
may use similar wording and procedures in their own services as the DOI System. 

In addition, an RA can request the DOI technical support service provider to configure the 
DOI Proxy to report a "DOI Name Not Found" error message to you in case the entered 
prefix is your prefix. 

See 5.4.5. 


40 https:/ /www.handle.net/client_download.html 
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Chapter 8 


REGI CIES 


The DOI Foundation defines high-level operational policy and assigns the execution of this 
policy to the Registration Agencies (see 2.3). The Registration Agencies enforce their own 
operational policies, specific to their community of interest. These specific policies will be 
consistent with the DOI Foundation's high-level policies. 


This chapter assists the Registration Agencies or registrants in defining their own policies. 


In This Chapter 


8.1 Defining a Prefix Allocation Policy <.icicictecdsesctsrecsnsa secnceaeioees stares pedi endo aatend 86 
8.2 Defining a Data Maintenance Policy <.cdlsiicncecsdierd eemuen ere aeiieeids nevis cise 86 
8.3 Defining a DOI Name Registration Policy isis: ciscc:.cectseissesinccpeceuredssieniedriesdoeerietndennineiets 86 
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8.1 DEFINING A PREFIX ALLOCATION POLICY 


As a Registration Agency (RA), you may choose to assign prefixes to your customers (see 
1.7.4). To do so, you should define a prefix allocation policy. 


The DOI Foundation allots to each RA prefixes as a block of sequential numbers that have 
no special meaning (prefixes are created by the DOI technical support service provider). 
No reserved prefixes may be requested. 


Some RAs will manage all assignments themselves and can operate under a single prefix. 
Others will want to delegate assignment to customers and in this case, it is recommended 
that prefixes are assigned at an appropriate level to deal with business requirements. Typi- 
cally, a Registration Agency (RA) may issue one prefix per customer, but it might also be 
appropriate to issue a prefix per brand, or to some recognizable cluster of products (for 
example, a publisher imprint). The choice is the RA's, but the DOI Foundation and/or other 
RAs can discuss requirements and make recommendations. 


NOTE Incase DOI names must be transferred from one RA to another, the foremost technical issue 
in this transfer is the one-to-one relation of prefix to Local Handle Service (LHS). In this perspective, 
RAs should allocate at least one separate prefix for each customer, and where appropriate more 
than one, since the fundamental constraint is that all DOI names under a given prefix must reside in 
the same LHS (this general architecture is a logical and efficient approach to a distributed service 
and is far from unique to the Handle System). 


8.2 DEFINING A DATA MAINTENANCE POLICY 


The effective operation of the DOI System depends on accurate resolution of a DOI name to 
the appropriate URL or other data type. To maintain quality services, it is also crucial that 
metadata assigned to a DOI name be regularly updated. Therefore, the maintenance of 
URLs and data about a DOI name should be subject to a policy. In particular, the policy 
should specify who, between the Registration Agency (RA), the registrant or a service or- 
ganization acting with the authority of the registrant, is responsible for the data mainte- 
nance. 


8.3 DEFINING A DOI NAME REGISTRATION POLICY 


You must define a policy which specifies: 
e that all DOI names must be registered in the DOI Directory (see 5.2) 
e who, between the Registration Agency or the registrant, generates the DOI names 


e the general scheme of the suffix to be followed, if any (for example, if another identifier 
scheme is integrated in the DOI name syntax) 


e the rules governing the suffix syntax (see also 3.2) with possible constraints from outside 
the DOI System on the suffix, for example: 


o onthe character set: see 3.4 
o on the suffix length 


e etc. 
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OPER 
MAI 
THER 


This chapter assists the Registration Agency's service operations team in performing service 
operation tasks. 


In This Chapter 


9.1 Defining Operational Processes... 6..<.:.cccsnecaesccosnsesdenoaseencoctansdenscnnsvencatnosaneaceeseneaacobenes 88 
9.2 Managing the User Access Rights .............:ccccccseececneeeeeeeeceeeeeceee cece eesseseecseseesueeeeaeeeeeaneess 88 
9.3 Issuing Prefixes to Registrants 5 .sce0 fact sass ccdonacsceaseonsntandens eat ssacpeapsadiccastonsnanesaeucenteuandhasneente 88 
9.4 Maintaining the Resolution Services...........ccccccseeccseeceeeeeceeeeeeeee cece eeseseeeseseesaeeeeaeeeeeaaeees 89 
9.5 Operating Your Own LHS 4 sesissiaceanseessav nerna n er E E ERSE AE AE Ai 89 
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9.1 DEFINING OPERATIONAL PROCESSES 


This section describes a DOI name registration process workflow example. 


NOTE If you want to allow DOI name administration from a local web server, you may use CNRI's 
net.handle.apps.admin_ servlets. Contact the Handle.Net Registry Administrator at 
hdladmin@cnri.reston.va.us for information. 


9.1.1 DEFINING THE DOI NAME REGISTRATION PROCESS 


Registration Agencies (RA) support registration of DOI names with an associated metadata 
declaration. Individual RAs develop their own workflow and procedures for the manage- 
ment of DOI name registration, and metadata deposit and maintenance, and provide their 
own information to their community of registrants. 

The service provided by each RA must include quality assurance measures, so that the in- 
tegrity of the DOI System as a whole is maintained at the highest possible level (delivering 
reliable and consistent results to users). This includes ensuring that the DOI record is accu- 
rate and up-to-date and that the DOI metadata is consistent and complies with both DOI 
Kernel and appropriate DOI data model standards. 


The general steps of the DOI name registration process are: 


1. The registrant sends to the RA data of DOI names to be registered. 
2. The RA creates the DOI names by registering them in the Handle System. 


3. The RA adds the appropriate registrant data to their metadata service. (At the current 
time there is no metadata database or mechanism for depositing metadata in a service 
run by the DOI technical support service provider.) 


4. The RA sends to the registrant the registration process results. 


9.2 MANAGING THE USER ACCESS RIGHTS 


Each Registration Agency administers the access rights and permissions for the DOI name 
registrants that form their community. They must provide adequate security to ensure that 
only the registrant (or someone acting with the registrant's permission) is able to maintain 
both metadata and DOI record data. 


For information about the user access right management in the Handle System, see the Digi- 
tal Object Identifier Resolution Protocol (DO-IRP) Specification*'. 


9.3 ISSUING PREFIXES TO REGISTRANTS 


An authorized Registration Agency issues prefixes to registrants where relevant and re- 
quests the DOI Directory Manager to register such new prefixes in the Handle System. The 
RA maintains the systems environment for storing a minimum set of descriptive metadata 
that can be provided and may be integrated with the Handle System. 


4 https:/ /www.dona.net/sites/default/files/2022-06/DO-IRPV3.0--2022-06-30.pdf 
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9.4 MAINTAINING THE RESOLUTION SERVICES 


The Registration Agency (RA) is responsible for taking the necessary steps to ensure the 
proper maintenance of their DOI prefixes and DOI names, including the following: 


e An administrator must be designated for each prefix (or set of prefixes): the prefix ad- 
ministrator can create DOI names under their prefix. 
The DOI technical support service provider also maintains administrative permission for 
the prefix. This is intended as backup for administration. Note that the creation of de- 
rived prefixes can only be done by the technical support service provider. 


NOTE The technical support service provider configures the prefix administrators in the prefix 
Handle (see 10.6). 


e Secure maintenance of private keys must be ensured by each administrator. 


e Service configuration changes must be timely reported to the DOI technical support ser- 
vice provider. 


e The RA must inform the technical support service provider and the DOI Foundation in the 
event of any major operation on the DOI names that could possibly interrupt the mirror- 
ing mechanism. 


e Additional requirements apply to RAs who operate their own LHS: see 9.5.3. 


9.4.1 TROUBLESHOOTING RESOLUTION PROBLEMS 


The DOI technical support service provider provides technical and operational support for 
the DOI System as a contractor. Further details of the relevant Agreement for Technical Ser- 
vices are available to potential and current Registration Agencies. 


If you receive an error message forwarded by the DOI technical support service provider, 
you must take the appropriate action. See the handling of resolution errors in the DOI Sys- 
tem in 5.4.5. 


9.5 OPERATING YOUR OWN LHS 


If a Registration Agency (RA) chooses to implement and operate a Local Handle Service 
(LHS) for their DOI names (see 5.2.2), the DOI technical support service provider will pro- 
vide the RA with the necessary technical guidance to help them install and administer their 
LHS. The technical support service provider is responsible for the scalability of the system 
and, in consultation with the DOI Foundation, for implementing future developments lead- 
ing to its growth and any improvement to its technical sophistication. 


9.5.1 INSTALLING THE LHS 
For information about the LHS installation, see Handle.Net Technical Manual”. 


The installation process will create a file called sitebnd1l.bin that will contain the service 
information for the LHS. As per the instructions in the distribution, you will need to send the 


42 https://www.handle.net/tech_manual.html 
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file to the DOI technical support service provider at doi-admin@doi.org. Name, organiza- 
tion name, and the fact that the request is coming from a DOI RA is important so that the 
technical support service provider knows to create prefixes that begin with 10. 


9.5.2 SETTING UP THE LHS 


You are responsible for modification of the configuration of your LHS to allow a secondary 
server installation at the DOI technical support service provider. The secondary server will 
house a complete database of the your DOI names. This requires a minor change in the 
server's configuration file. This will be coordinated by the technical support service pro- 
vider. After setup is complete a regularly executing task (for instance, a cron job) will be 
created to check to see if the secondary server is able to connect to your server. If there is 
problem with the connection (for example, your server is shut down) you will be notified by 
email and expected to correct the problem as soon as possible. 


For more information about LHS setup, see Handle.Net Technical Manual”. 


9.5.3 LHS OPERATION REQUIREMENTS 


Maintaining overall integrity of the Handle System entails ensuring that each of the follow- 
ing conditions is met by administrators, who must agree to operate their resolution services 
during the period while the authorization is in effect. The term "system" as used below refers 
to those components run by each administrator, and the interaction of these components 
with the Global Handle Registry (GHR) and the users of the Local Handle Service (LHS). 
Operational goals for administrators include: 


e Ensuring compatibility and smooth interaction among system components 

e maintaining consistency and reliability in service performance 

e conducting proper system management and performance tracking 

e offering non-interrupted access to the GHR 

e taking adequate system security measures 

It is also the responsibility of the Registration Agency to inform the DOI technical support 


service provider of any configuration changes in their LHS. 


NOTE A number of utilities for low-level maintenance of a Handle server are available such as 
net.handle.apps.tools and net.handle.apps.site_tool. Contact the DOI technical support 
service provider at doi-admin@doi.org. 


9.6 TRANSFERRING DOI NAMES FROM ONE REGISTRANT TO 
ANOTHER 


If a compilation of multiple assigned DOI names (for example, a journal containing a col- 
lection of articles; an imprint; a recording catalogue; etc.) is transferred from one registrant 
to another (both registrants being related to the same Registration Agency (RA)), the DOI 
names within that compilation are transferred as well. Each RA will develop appropriate 


4 https:/ /www.handle.net/tech_manual.html 
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procedures for proper transfers. Transfers may be a sale, or any form of exchange, com- 
mercial or otherwise. If the new owner is not already a registrant, special arrangements 
may have to be made appropriate to the case. Consult the DOI Foundation for guidance if 
necessary. 

The individual DOI names stay the same, it means that what the DOI name identifies is not 
changed. This is a fundamental requirement. The DOI name prefix does NOT change (recall 
that a prefix is not meaningful, but is initially assigned to a registrant for convenience in 
generating DOI names only; no reverse look-up can be inferred to a prefix). The adminis- 
trative value is changed in order for the new owner to modify its data elements (most likely 
the URL element). Both registrants involved in the transfer need to send email to the DOI 
technical support service provider at doi-admin@doi.org giving permission for the transfer. 
The technical support service provider will assist RAs to ensure an efficient and successful 
outcome. 


9.7 TRANSFERRING DOI NAMES FROM ONE REGISTRATION 
AGENCY TO ANOTHER 


Moving an entire prefix worth of DOI names from one Registration Agency (RA) to another 
is easy. Splitting control of a prefix between two administrative bodies who both use the 
same Handle service (it means, when it has not been possible to foresee a split by issuing 
separate prefixes) is also possible but more complex. In general, there are two solutions: 
1. leave it with one or the other service (or the DOI default Handle service run by the DOI 
technical support service provider on behalf of the DOI Foundation) and split up the ad- 
ministration, such that the managers of one service allowed the 'foreign' admins access 
2. alias all the DOI names under the old prefix to DOI names under a new prefix controlled 
by the new RA 
The old DOI names do not have to be maintained other than ensuring resolution to the 
new DOI names. 
All of the above is strictly from a DOI System point of view and does not address any inter- 
nal workflow issues or value-added services that the RAs provide that interact with Handle 
administration, which would of course be specific to the RA. 
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10.1 DOI KERNEL SCHEMA 


The DOI Kernel Schema is an XML schema (also called DOI Kernel XML Schema). It speci- 
fies the DOI Kernel Metadata and all data elements and allowed values (data dictionary) of 
the metadata exchange schemas. It is maintained by the DOI Foundation. 

It consists of two files available on the DOI web site: 

e DOI Schema“ 

e DOI Schema AVS* (Allowed Value Sets) 


10.1.1 DOI KERNEL ELEMENTS 

This section describes the elements of the DOI Kernel. These descriptions are based on the 
extensible kernel contained in ISO 26324. Additional terms beyond those stated in ISO 
26324 may be listed but only for terms which are open lists for which new items may be 
registered. 


DESCRIPTIVE ELEMENTS 
The table below lists the descriptive elements used in DOI Metadata Kernel. 


Table 4 DOI Kernel: descriptive elements 


[DOIlname foo Specific DOI name allocated to the identified referent. 


referentldentifier(s) Other identifier(s) referencing the same referent (examples: ISAN, ISBN, 
ISRC, ISSN, ISTC, ISNI). 
This element contains a type element appropriate to the primaryRefer- 
entType. The schema at present recognises a creationldentifierTy pe and 


partyldentifierType, which are open lists" 


referentName(s) Name(s) by which the referent is usually known (example: title). 
This element contains a type element appropriate to the primaryRefer- 
entType. The schema at present recognises a creationNameType and par- 


tyNameType, which are open lists”. 


This element also contains a language element, for which the allowed 
value list is the ISO 639-2 code list. 


primaryRefer- The primary type of the referent (examples: creation, party, event). This is 
entType an open list”. 


4 https://doi.org/10.1000/276 
4 https://doi.org/10.1000/282 
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structurallype 


character 


referentlype 


linkedCreation 


linkedParty 


principalAgent 


dateOfBirthOrFor- 


mation 


DOI Handbook 


The primary structuralType of a referent. 

For creations, there are four mutually exclusive creationStructurallTypes 
(physical, digital, performance, abstraction) that allow classification ac- 
cording to overall form. Where structurallypes may be contained within 
one another, the referent's structuralType is defined by the overall form 
(for example, a CD (physical) may contain files (digital) which contain re- 
cordings of performances of songs (abstractions)), and elements of con- 
tent can be further classified if necessary under referentType. 

For parties there are three mutually exclusive partyStructuralTypes (per- 
son, animal, organization). These lists are closed”. 

For creations only, the principal sensory mode(s) by which a referent is in- 
tended to be perceived (audio, visual, tangible, olfactory, tasteable, 
none). Mode identifies only the principal intended modes of perception. 
Most physical resources are perceivable with all five senses, but some of 
these perceptions may be trivial. For example, a printed book may be 
touched or smelled, but these are supplementary or incidental to visual 
mode, the intended function as a content carrier. For a Braille book, how- 
ever, tangible would be a principal mode. This list is closed”. 

For creations only, a fundamental form of communication in which the 
content of a referent is expressed. There are four values: music, language, 
image, other. This list is closed”. 

Specification of type(s) of referent for parties: author, composer, book 
publisher, library, university, financial institution, film studio. 

For creations, the abstract nature of the content of a referent, irrespective 
of its creationStructuralType, is typically described by creationType, which 
may be extended as needed to include format and genre elements (exam- 
ples: audio file, scientific journal, musical composition, dataset, serial arti- 
cle, eBook, PDF). 

For parties, referentType is a role with which the party is associated and is 
described by associatedPartyRole (examples: Composer, Author, Book- 
Publisher, JournalPublisher). 

This is an open list”. 

For creations only. Another creation with which a referentCreation is asso- 
ciated. 

This element contains a creationRoleToCreation element, which is an open 
list for which new allowed values may be registered. 

For parties only. Another party with which a referentParty is associated. 


This element contains a partyRoleToParty element, which is an open list”. 
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dateOfDeathOrD- For parties only, the date of death (for an individual or animal) or dissolu- 
issolution tion (for an organization) of the referentParty. 


associatedTerritory For parties only, a territory with which the referentParty is associated (ex- 
amples: a territory of birth, nationality or residence). The allowed value 
list is the ISO 3166a2 territory code list. 


1) Registration Agencies can request the addition of new allowed values to open lists (see 4.3.6). 


2) No new values can be added to closed lists. 


ADMINISTRATIVE ELEMENTS 
The table below lists the descriptive elements used in DOI Metadata Kernel. 


Table 4 DOI Kernel: administrative elements 


Code assigned to denote the name of the agency (author- 
ized by the ISO 26324 Registration Authority) that issued 
this DOI name. 


Date when this DOI name was issued. 


issueNumber Number or other designation associated with the specific 


version of the DOI Kernel Metadata Declaration. 


10.2 DOI NAME ENCODING 


This section contains various information related to DOI name encoding. 


10.2.1 UTF-8 ENCODING OF NON-ASCII CHARACTERS 


UTF-8 is a Unicode encoding that allows characters to be encoded in terms of one to six oc- 
tets. UTF-8 encoding plays a role when non-ASCII characters are used. For example, the 
Japanese word "nihongo" is written as: 


=H 
AA 


The Unicode sequence representing the Han characters for "nihongo" is: 65E5 672C 8A9E. 
These may be encoded in UTF-8 as follows: E6 97 A5 E6 9C AC E8 AA 9E. 


For further information on UTF-8 see RFC 3629. 


10.2.2 DOI NAME ENCODING RULES FOR URL PRESENTATION 


Hex-encoding must be used when presenting a DOI name as a Uniform Resource Locator 
(URL) if the DOI name contains characters that are not allowed, or have other meanings, in 
the URL application context. Hex-encoding consists of substituting for the given character its 
hexadecimal value preceded by percent. For example, # becomes %23 and 
https: / /doi.org/ 10.1000/456#789 is encoded as 

https: / / doi.org/ 10.1000/456%23789 (Thus, the browser does not now encounter the 
bare #, which it would normally treat as the end of the URL and the start of a fragment, and 
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so sends the entire string off to the DOI network of servers for resolution, instead of stop- 
ping at the #.). 

The table below lists the mandatory and recommended hex-encoding rules (the recommen- 
dation was established based on a practical experience of the current web browsers). 


— 5 DOI name encoding rules 


er necessary in a Which RA service request %2C 
context) 


NOTE The web browser treatment of /./ and /../ can be inconsistent. It is recommended that 
one of the slashes be percent encoded, for example, /./ is changed to /.%2F and /../ to 
/ .%o2F. 


NOTE To enable the use of DOI names in workflows that have already standardized on URNs, the 
DOI proxy servers understand the substitution of a colon in place of the initial slash in a DOI name. 
DOI names may therefore be expressed as URNS in the doi.org domain by writing, for example, 
the DOI name 10.123/456 in the form hitps:/ / doi.org/urn:doi:10.123:456. However, a DOI 
suffix is allowed to contain other slashes, and where these occur they must be hex-encoded rather 
than replaced with a colon: for example, the DOI name 10.123/456ABC/zyz would become 
https: / /doi.org/urn:doi:10.123:456ABC%2Fzyz, with the final slash character encoded as %2F. 


10.3 DOI PROXY QUERY COMMAND FORMAT 


The format of a resolution query command to the DOI Proxy (see 5.3.1) is as follows: 
https://doi.org/<doi-name>?<param_1>&<param_2>é.. 
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where: 

e <doi-name>: DOI name to be resolved 

e <param_i>: parameter i passed to the DOI Proxy 

Example: https://doi.org/10.1000/1?noredirect&type=URL 


NOTE HTTP instead of HTTPS as well as dx.doi.org instead of doi.org are still supported (but not 
recommended). 


The following table lists the native parameters supported in a query sent to the DOI Proxy. 


(Other parameters may be passed through the proxy using the urlappend parameter.) 


Table 6 DOI Proxy: query parameters 


Do not redirect using URL or 10320/loc type elements. Display the elements 
instead. 


ignore_aliases | Ignore HS_ALIAS elements. 
The HS_ALIAS element is used to specify a Handle that should be resolved in- 


stead of the input Handle. 


auth Authoritative query. The DOI Proxy bypasses its cache and sends its resolu- 
tion request to an authoritative Handle service (it means to a primary service, 
not to a mirror service). 

cert Certified query. The DOI Proxy requires an authenticated response from the 
Handle service (it means that the DOI Proxy asks the Handle service to sign 
its response and the Proxy will check the signature before accepting it). 


index=<value> | Resolve the DOI record element at the specified index value and do not re- 
solve the other elements except if otherwise required. May be repeated to re- 
solve multiple indexes. 
type=<value> Resolve the DOI record element of the specified type value and do not re- 
solve the other elements except if otherwise required. May be repeated to re- 
solve multiple types. 
urlap- Append the value of this parameter to the end of the URL used for redirec- 
pend=<value> | tion. 
locatt=<key>:<v | In case of a multiple resolution: use this key:value pair for the interpretation 
alue> of the 10320/LOC element. 
action=showurls | In case of a multiple resolution: return an XML representation of the possible | 5.4.2 
redirect locations stored in the 10320/LOC element. 
All combinations of parameters are accepted (not all are useful). For example, if the index 


and type query parameters are used together then any element which matches any of the 
specified indexes or types is returned. 


10.4 DOI REST API REQUEST AND RESPONSE FORMATS 


The DOI Proxy REST API allows programmatic access to DOI name resolution using 
HTTP(S). 
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10.4.1 REST API REQUEST FORMAT 


A REST API request can be made by performing a standard HTTPS GET of /api/han- 
dles/<doiName>: 


https://doi.org/api/handles/<doiName>?<param_ 1>&<param_2>&.. 
where: 
e <doiName>: DOI name to be resolved 


e <param_i>: parameter i passed to the DOI Proxy REST API 


Example: https://doi.org/api/handles/10.1000/1?type=URL&callback=processRespons 
The table below lists the parameters supported in a query sent to the DOI Proxy REST API. 


Table 7 DOI API query parameters 


callback Use JSONP callback (instead of CORS headers) 
Pretty-print the JSON output 


auth Authoritative query. The DOI Proxy bypasses its cache and sends its resolution request to 
an authoritative (primary) Handle service. 


cert Certified query. The DOI Proxy requires an authenticated response from the Handle ser- 
vice (it means that the DOI Proxy asks the Handle service to sign its response and the 
Proxy will check the signature before accepting it). 

index” Resolve the DOI record element at the specified index and do not resolve the other ele- 
ments except if explicitly required. May be repeated to resolve multiple indexes. 

type” Resolve the DOI record element of the specified type and do not resolve the other ele- 
ments except if explicitly required. May be repeated to resolve multiple types. 

1) The index and type query parameters can be used together: any element which matches any of the 

specified indexes or types is returned. 
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10.4.2 REST API RESPONSE FORMAT 


The REST API response is a JSON object which includes a response code, an echo of the re- 


solved Handle identifier, and either a list of DOI record elements or, in the case of an er- 
ror, an optional message which is a string describing the error. The figure below shows a 
response example. 


List of 
elements in 
the DOI 
record 


“responseCode”: Identifier of the 
"handle": resolved DOI name 


“values”: [ 


~~ 


“index”: 100, 
“type”: "HS ADMIN", 
"data": { 
"format": "admin", 
"value": { 
"handle": "0.NA/10.1000", 


"index": 200, 
"permissions": "011111111111" 
} 


e 
"ttl": 86400, 
“timestamp”: "2000-04-13T15:08:572" 


“index”: i, 
“type”: “URL”, 


"data": { "format": "string", "value": "“https://www.doi.org/index.html" 


"ttl": 86400, 
“timestamp”: "2004-09-10T19:49:592" 


Figure 22 REST API response example 
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RESPONSE CODE 


The response code is an integer referring to a Handle System protocol response code. The 
most common response code values are: 
1 : Success. (HTTP 200 OK) 


2 : Error. Something unexpected went wrong during DOI name resolution. (HTTP 500 In- 


ternal Server Error) 
100 : Handle Not Found. (HTTP 404 Not Found) 


200 : Values Not Found. The Handle Record exists but the required elements do not ex- 
ist. 


ELEMENT DATA 


An element consists of: 

e an index (an integer): unique element identifier inside the Handle Record 

e a type (a string): for example, URL, description, IP address, email address, etc. 

e a value (a data object): see table below 

e a timestamp (an ISO8601 -formatted string): date and time of the last data update 


e a Time To Live (TTL; an integer, or, in the rare case of an absolute expiration time, an 
1SO8601-formatted string): specifies how long the element value can be cached before 
the information source should again be consulted 


The table below describes the "value" property depending on the "format" property of the 
element data object. For more information about HS_ADMIN, HS_VLIST and HS_SITE data, 
see Digital Object Identifier Resolution Protocol (DO-IRP) Specification”®. 


Table 8 Element value ("data" object) 


Is a string representing the data as a UTF-8 string. 
Is a string, with a BASE64 encoding of the data. 
Is a string, with a hex encoding of the data. 


Is an object representing an HS_ADMIN element (Handle administrator) with 

the properties: 

"handle": identifier of the Handle used to identify the administrator 

"index": index of the element in the administrator's Handle Record storing the 

administrator's public key 

"permissions": access rights to the Handle Record granted to the administrator 


"ylist" Is an object representing an HS_VLIST element (refers to a list of administrators 
(public keys in Handle Records)) 


"site" Is an object representing an HS_SITE element (Handle service site information). 
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10.5 10320/LOC ELEMENT 


This section contains details about the 10320/LOC element used in the multiple DOI resolu- 


tion (see 5.4.2). 


10.5.1 


The 10320/LOC type is used in a DOI record to describe complex location selection rules 
in XML format. The following table lists the XML attributes supported in these rules. 


10320/LOC: XML ATTRIBUTES 


Table 9 10320/loc: XML attributes 


chooseby 


The URL for the location. Yes 


46 https:// www.dona.net/sites/ default/files/2022-06/DO-IRPV3.0--2022-06-30.pdf 


Identifies a comma-delimited list of location selection methods: the DOI re- 
solver will iterate over the selection methods in the specified order. For each 
applied selection method: 

If one and only one location is selected then the DOI resolver will redirect to 
this location. 

Otherwise, the DOI resolver will apply the next selection method. If no selec- 
tion method is left then the DOI resolver will apply the weighted method which 
guarantees to return a single location. 

If no chooseby attribute is specified then the default ("locatt, coun- 

try, weighted") is assumed. 

Possible location selection methods: 

locatt: Only locations from an attribute passed in the Proxy/ DOI name-URL 
link are selected. 

Example: With doi:10.123/4562locatt=id:1, the resolver will return the loca- 
tions that have an "id" attribute of 1. 

country: Only locations that have a country attribute matching the country of 
the requester are selected. If no matching locations are found then locations 
that have no country attribute are selected. 

Note: The hitps://hdl.handle.net and https:/ /doi.org Proxies determine the 
country of the requester using a GeolP” lookup. 

weighted: A single location is selected based on the weight assigned to each 
location: 

A location with no weight attribute is assumed to have weight one. 

A higher weight is selected first. 

If several locations have the same weight then a random choice is performed. 
If the weighted selection method is applied to locations that all have non -posi- 
tive weights, then this method selects one of the remaining locations randomly 
while disregarding location weights. 

Note: The weighting allows for a very basic load balancing, but is also a way 
to ensure that some locations can only be addressed directly (for example, by 
country or locatt/ attributes). 


4 https://www.maxmind.com/en/geoip2-services-and-databases 
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weight The weight (a floating point between zero and one) that should apply to this | No 
location when performing a weighted selection. 


country Country of the requester. Possible values: two-letter country codes according | No 
to ISO 3166-1. 


10.5.2 10320/LOC: EXAMPLE 
The table below shows the DOI record returned for doi:10.123/456. 
Table 10 DOI record with redirection graph 


ao {uRL o O) https:/ /www.defaultexample.com 


10320/LOC | <locations> 
<location id="0" href="https:/ / uk.example.com/" country="gb" 
weight="0" /> 
<location id="1" href="https:/ / www 1.example.com/" weight="1" /> 
<location id="2" href="https:/ / www2.example.com/" weight="1" /> 
</locations> 


With this example, the DOI resolver will apply the default selection method order - it 
means: 1) locatt; 2) country; 3) weighted - as illustrated below. If the DOI resolver does 
not understand the 10320/LOC element type (or is requested to ignore it), then it will se- 
lect the URL element type: https:/ / www.defaultexample.com. 


Table 11 Resolution request examples with result 


10.123/456 from a . The locatt method does not apply. https:/ /uk.example.com/ 
requester located in . The resolver applies the country method. It 
the UK selects https://uk.example.com/ and stops 

(single matching selection). 
10.123/456 from a . The locatt method does not apply. https:/ /www1.example.com/ 
requester located out- | 2. The resolver applies the country method: no | or https:/ /www2.exam- 
side of the UK URL can be selected. ple.com/ 

. The resolver applies the weighted method to 

https:/ /www1.example.com/ and 

https:/ /www2.example.com/. They have 

the same weight, it selects one of these two 

URLs randomly. 


10.123/4562locatt= | 1. The resolver applies the locatt method with https:/ /www1.example.com/ 
id:1 id="1". It selects https://www 1.exam- 


ple.com/ and stops (single matching selec- 
tion). 


10.123/4562locatt= | 1. The resolver applies the locatt method with https:/ /uk.example.com/ 
id:0 id="0". It selects https:/ / uk.example.com/ 
and stops (single matching selection). 
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10.123/4562locatt= 
country:gb 


10.123/456?2locatt= 
country:us with re- 
quester located in US 


. The resolver applies the locatt method with 


country="gb". It selects https: / /uk.exam- 
ple.com/ and stops (single matching selec- 
tion). 


. The resolver applies the locatt method with 


country="us": no URL can be selected. 


. The resolver applies the country method with 


the country of the requester: no URL can be 
selected. 


. The resolver applies the weighted method to 


https://www 1 .example.com/ and 
https:/ / www2.example.com/. They have 


the same weight, it selects one of these two 
URLs randomly. 


10.5.3 10320/LOC AT PREFIX LEVEL 


Any location information (information specified through a 10320/LOC element) that ap- 
plies to all or most DOI names under a prefix can be stored at prefix level: this information 
applies to all DOI names under that prefix. If specific location information is stored at DOI 
name level then this information overrides information stored at prefix level. 


https:/ /uk.example.com/ 


https:/ /www1.example.com/ 
or https:/ / www2.exam- 
ple.com/ 


Location information is stored at prefix level by using the HS_NAMESPACE element in the 
record of the prefix Handle (0O.NA/<prefix>): the HS_NAMESPACE element points to an- 
other Handle or DOI name which will store a 10320/LOC element. Typically, this element 
will contain URL templates. For more information about the HS_NAMESPACE element, see 


the Handle.net Technical Manua 


|48 


48 https://www.handle.net/tech_manual/HN_Tech_Manual_9.pdf 
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The following figure shows the example of the prefix Handle O.NA/ 10.5237 where the 
10320/LOC element is stored in the prefix record. 


Last Modified: 2010.12.06 16:44:09 CET Expiresiniday adminrw public:r- index: 2 
DESC: MovieL abs prefix. 
Last Modified: 2010.12.06 16:44:22 CET Expires in 1 day adminrw publicr- index: 3 


4 
$ 
$ 
HS_SIGNATURE: O ANA AANE R 
Last Modified: 2022.05.06 21:30:18 CEST Expires in 1 day admin:rw public:r- index: 400v 
Figure 23 10320/LOC at prefix level 
10.6 PREFIX HANDLE EXAMPLE 
The figure below shows the record of the prefix Handle 0.NA/ 10.1009. 
[LE] View Handle: 0.NA/10.1009 
File Tools 
; HS_ADMIN: handle=0.NA/10. 1009; index=200; [create hdl,read val] 
Last Modified: 2014.10.09 20:40:51 CEST Expiresiniday adminyw publics. index: 100 
> HS_ADMIN: handle=0.NA/10; index=200; [create hdl,delete hdl,create derived prefix,delete derived prefix,read val,modify* 
Last Modified: 2000.04.10 00:46:15 CEST Expiresiniday adminrw public. index: 101 
S HS_SERV: 10.SERVICROSSREF 
Last Modified: 2016.09.21 22:45:22 CEST Expires in 1day admin:rw public:r- index: 1 
HS_VLIST: 300:10.cradminhmhco 
= Last Modified: 2014.10.09 20:40:37 CEST Expires in 1 day adminsw publics. index: 200 
EMAIL: support@crossref.org 
Sy Last Modified: 2014.10.09 20:40:18 CEST Expires in 1 day adminrwpublicr- index: 3 3 
AS | SIGNATURE: eyJhbGciOiJSUZzI1NIJ9.eyJkaVdic 3IRzljp7imFsZyISIINIQSONTYILCJkadic3RzijpbeyJpbmRleCiőMTA wl 3 
Last Modified: 2022.01.30 03:02:52 CET Expires in 1 day adminsrwpublicy- index: 400 3 


Figure 24 Prefix Handle Record example 
The table below describes the elements of the 0.NA/ 10.1009 record. 
Table 12 0.NA/ 10.1009 elements 


HS_ADMIN RA or registrant's prefix administrator: can create Handles (DOI names) 


under prefix 10.1009. 
This administrator is identified 1) by 200:0.NA/ 10.1009 which points to 
the index 200 in this identifier (HS_VLIST). 
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HS_ADMIN 


4 HS_VLIST 


Eel 


1) An administrator is identified in the Handle System by a public key stored in a Handle Record (in this 
example, the public key is at index 200 of 0.NA/ 10.1009 record). User authentication is performed by a 
Handle System service through a PKI challenge-response. 


10.7 SYSTEM TOOLS 


The DOI technical support service provider provides servlets and tools that some users and 
programmers may find useful. The table below lists some of them. Contact the DOI technical 
support service provider at doi-admin@doi.org for information. 


Table 13 Handle tools 


net.handle.batch.DOIBatch A batch loader for DOI names. 


net.handle.apps.admin_servlets |The servlets used for administering Handles via the web, useful if you 
want to allow DOI name administration from a local web server. 


net.handle.apps.simple If you do decide to roll your own Handle software, this package has a 
number of examples of how to use the Handle client library. 
net.handle.apps.tools, A number of utilities for low-level maintenance of a Handle server. 


net.handle.apps.site_tool Make sure to check there before writing anything along these lines 
yourself. 
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GLOS 


This section contains terms which are relevant to the document content. The terms marked * 
are as specified in ISO 26324. 


A 


actionable 
Capable of resolution by a system on the Internet. For example, in an Internet Web browser, an 


actionable identifier can be "clicked on" and some action takes place. 


allowed value* 


An item which may be used as a value of an element. 


API 

Application Programming Interface. A way for two or more computer programs to communicate 
with each other. It is a type of software interface, offering a service to other pieces of software. A 
document or standard that describes how to build or use such a connection or interface is called an 
API specification. A computer system that meets this standard is said to implement or expose an 


API. The term API may refer either to the specification or to the implementation. 


D 


Data Dictionary * 
A repository for all data elements and allowed values of those elements used in DOI 


metadata declarations. 


DO 
Digital Object. A sequence of bits, or a set of sequences of bits, that is used to represent a digital, 
physical or virtual entity in the Digital Object Architecture (DOA). 


DOI Directory 
A virtual service consisting of Handle System services and web proxies located and configured to 


provide highly reliable resolution, administration, and backup for all DOI names. 
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DOI metadata 
Metadata associated with a referent within the DOI System, based on a structured data model that 


supports unambiguous description and services. 


DOI name* 


A string that identifies a unique object within the DOI System. 


DOI Proxy 

A web server that understands the Handle System protocol (DO-IRP), thereby acting as a gateway 
between the DOI System and HTTPS, enabling resolution of a DOI name in the URL https:// syn- 
tax. Any standard browser encountering a DOI name represented in this form will be able to re- 


solve it without the need to extend the web browsers capability. 


DOI record 


The set of elements to which a DOI name can be resolved. 


DOI syntax* 
Rules for the form and sequence of characters comprising any DOI name, specifically the form and 


character of a prefix element, separator and suffix element. 


DOI System* 
Social and technical infrastructure for the assignment and administration of DOI names as identifi- 
ers in computer-readable form through assignment, resolution, referent description, administration, 


etc. 


G 
GHR* 


Global Handle Registry. A component of the Handle System which provides first-level resolution of 
Handles. Stores the information necessary to locate the LHS responsible for any Handle in the sys- 


tem. 


H 


Handle 
Actionable identifier concept underlying the Handle System. 


Handle System’ 

The technology used as the resolution component of the DOI system. The Handle System is a gen- 
eral-purpose distributed information system designed to provide an efficient, extensible, and se- 
cured global name service for use on networks such as the Internet. The Handle System is a particu- 
lar implementation of the DO-IRP (Digital Object - Identifier / Resolution Protocol) which is part of 
the Digital Object Architecture (DOA). 
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HTTP 

Hypertext Transfer Protocol. An application layer protocol in the Internet protocol suite model for 
distributed, collaborative, hypermedia information systems. HTTP is the foundation of data commu- 
nication for the World Wide Web, where hypertext documents include hyperlinks to other re- 
sources that the user can easily access, for example by a mouse click or by tapping the screen in a 


web browser. 


HTTPS 
Hypertext Transfer Protocol Secure. An extension of HTTP. It is used for secure communication over 
a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is 


encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). 


| 
INDECS 


INteroperability of Data in E-Commerce Systems. A project, set of principles, and tools, resulting in 
a framework, derived from a multi-participant project conducted 1998-2000. Provides the analyti- 


cal basis for the DOI System's approach to metadata. 


interoperability * 
Ability of independent systems to exchange meaningful information and initiate actions from each 


other, in order to operate together to mutual benefit. 


International Organization for Standardization (ISO) 
Standards setting organisation with National Standards Bodies as members which publishes inter- 


national standards and other documents. 


ISO 26324 
ISO 26324 Information and documentation — Digital object identifier system. The international 
standard published by ISO which specifies the DOI System. The 2022 document is the second edi- 


tion and revises the original document published in 2012. 


K 


Kernel metadata 


A compulsory, small standardized set of metadata elements assigned to each DOI name. 


L 
LHS 


Local Handle Service. A component of the Handle System which provides resolution and admin- 


istration services for Handles belonging to a given namespace. 
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Linked Data 

Structured data which is interlinked with other data so it becomes more useful through semantic 
queries. It builds upon standard Web technologies such as HTTP, RDF and URIs, but rather than us- 
ing them to serve web pages only for human readers, it extends them to share information in a way 


that can be read automatically by computers. 


M 


metadata* 
Specific data associated with a referent within the DOI System based on a structured data model 
that enables the referent of the DOI name to be associated with data of any desired degree of pre- 


cision and granularity to support identification, description and services. 


multiple resolution 


Resolution of a DOI name returning multiple resources. 


O 


opaque string* 
Syntax string that has no meaning discernible by simple inspection. (To discover meaning, 


metadata is required.) 


P 


persistence* 
Existing, and able to be used in services outside the direct control of the issuing assigner, without a 


stated time limit. 


R 
RA 


Registration Agency. An RA provides DOI-based services to one or several communities of users. 


An RA can be considered as a module of the DOI System, serving a constituency. 


RDF 
Resource Description Framework. A World Wide Web Consortium (W3C) standard originally de- 
signed as a data model for metadata. It has come to be used as a general method for description 


and exchange of graph data. 


RDF / XML 
A syntax defined by the W3C to express (serialize) an RDF graph as an XML document. 
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referent* 


Entity identified by a DOI name. 


registrant 
The registrant of a DOI name provides and maintains the metadata assigned to the DOI name. 


They may also assign the DOI name suffix. 


registration authority 
Entity appointed by ISO to manage the allocation of names to codes under the auspices of an inter- 
national standard. A registration authority agreement between ISO and the registration authority 


sets out the obligations and responsibilities of each. 


resolution” 
Process of submitting a DOI name to a network service and receiving in return one or more pieces 
of current information related to the identified object such as a location (URL) of the object or an 


email address, etc. 


REST 
REpresentational State Transfer. An architectural style that defines a set of constraints to be used for 


creating web services. REST API is a way of accessing web services in a simple and flexible way. 


S 


single resolution 


Resolution of a DOI name returning a single URL. 


U 
URL 


Uniform Resource Locator. Colloquially termed a web address, is a reference to a web resource 
that specifies its location on a computer network and a mechanism for retrieving it. URLs occur most 
commonly to reference web pages but are also used for file transfer, email, database access, and 


many other applications. 
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